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NATIONAL FOREWORD 

This Indian Standard which is identical with ISO/TR 10562 : 1995 * Manipulating industrial robots — 
Intermediate Code for Robots (ICR)' issued by the International Organization for Standardization (ISO) was 
adopted by the Bureau of Indian Standards on the recommendations of Industrial and Production Automation 
Systems and Robotics Sectional Committee (BP 18) and approval of the Basic and Production Engineering 
Division Council. 

This standard does not include the development of individual standards themselves but rather the establishment 
of common frame work, in terms of a reference model to assist future standards development. 

The text of the ISO Standard has been approved as suitable for publication as Indian Standard without deviations. 
Certain conventions are, however, not identical to those used in Indian Standards. Attention is particularly 
drawn to the following: 

Wherever the words *Techincal Report' appear referring to this standard, they should be read as 'Indian 
Standard'. 

In the adopted standard, reference appears to the following International Standard for which Indian Standard 
also exists. The corresponding Indian Standard which is to be substituted in its place is listed below along with 
its degree of equivalence for the edition indicated: 

International Standard Corresponding Indian Standard Degree of 

Equivalence 

ISO 8373 : 1994 Manipulating IS 14662 : 1999 Manipulating industrial Identical 

industrial robots — Vocabulary robots — Vocabulary 

At present there is no corresponding Indian Standard to ISO 8859-1 : 1987 and ISO/IEC 9506-3 : 1991. The 
technical committee responsible for the preparation of this standard has reviewed the provisions of the above 
mentioned ISO/IEC Standards and decided about the acceptables for use in conjunction with this standard. 
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Indian Standard 

MANIPULATING INDUSTRIAL ROBOTS — 
INTERMEDIATE CODE FOR ROBOTS (ICR) 



1 Scope 

This Technical Report specifies an intermediate code to be used as a neutral interface between user- 
oriented robot programming systems and industrial robot control systems and to define the structure of 
and the access mechanisms to data lists, which contain data accompanying the intermediate code. 

2 Normative references 



The following standards contain provisions which, through reference in this text, constitute provisions of 
this Technical Report. At the time of publication, the editions indicated were valid. AH standards are 
subject to revision, and parties to agreements based on this Technical Report are encouraged to 
investigate the possibility of applying the most recent editions of the standards listed below. Members of 
lEC and ISO maintain registers of currently valid Intemational Standards. 

ISO 8373 : 1994, Manipulating industrial robots - Vocabulary. 

ISO 8859-1 : 1987, Information processing - 8-bit single-byte coded graphic character sets - Part 1: 
Latin alphabet No, L 

ISO/IEC 9506-3 : 1991, Industrial automation systems - Manufacturing message specification - Part 3: 
Companion standard for robotics. 
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3 Definitions 



For the purposes of this Technical Report, the definitions given in ISO 8373, and the following, apply. 

All code and data elements will be represented in accordance with ISO 8859-1 (8-bit character set). ICR 
is machine or interpreter-oriented instead of user-oriented. 

The following words are used in the specialized definition in this Technical Report. 

3.1 ICR program: Collection of robot directives and data written in ICR. 

3.2 data list: Collection of positions, poses and other data structures written in ICR codes. 

3.3 robot control unit: Controlling device which accepts instruction codes and sends servo signals to 
each joint of an industrial manipulator. 

4 Compliance with this Technical Report 

A program code complies with this Technical Report if it uses only the features of the code that are 
defined by this Technical Report and it does not rely on any particular interpretation of implementation- 
dependent features. 

The single statements of the Technical Report can be divided into two groups. 

The first group (A) contains the statements whose implementation is independent of the industrial robot 
control and the robot type to be controlled. 

The second group (B) contains the statements that are dependent on a specific industrial robot type and 
robot control. 

The group A is divided into 8 compliance levels. 

The basic level (level 0) of group A contains: 

Memory and data management 

Program flow control 

Boolean and arithmetic operations 

The statements 

CNFGCHAN, OPENCHAN, CLOSECHAN, RESETCHAN, STATCHAN, 
DIN and DOUT of the exchange of datastatements 

Each addressing mode except symbolic addressing 
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As extension of the basic level there are 7 compliance levels , which can extend the basic level 
independent from each other. 



1 Symbolic addressing mode 



2 Exchange of data statements except 

CNFGCHAN, OPENCHAN, CLOSECHAN, RESETCHAN, STATCHAN, 
DIN and DOUT 



3 Data list management 

4 Sensor functions 



5 Debugging functions 

6 User specific extensions 

7 Future extensions 



The group B is divided into a kernel and an extension. 

j 

The kernel of grpupB contains: 



ACCEL, VEL, and MOVTIM statements 

JMOVE and LMOVE statements 

CALIB, CURPOS, GOHOME, MOVSTP, MOVCONT, and MOVCANCEL 

statements 
Description of end effector facilities 



The extension of group B contains: 



Each technical specification not contained in the kernel 
Each move and effector control not contained in the kernel 
Description of robot facilities 



An ICR processor is defined by this Technical Report to be "a system or mechanism that accepts an ICR 
code as input and executes ICR code according to the semantics- defined by the standard". A processor 
complies with the standard if it satisfies at least the basic level of group A and the kernel of group B, 
except of those functions of the kernel of group B that are explicitly reported by the processor to be not 
accepted. 

ICR may be represented in two different forms. 

In the first form all operators only consist of ASCII-character digits. The second form allows mnemonics 
to express the operators. The effect of the following two statements is exactly the same: 



and 



a) 220,5450; 

b) 220, MOVEND'; 
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In statement a) the operator is a number, while in b) the operator is in the form of a mnemonic. 

Due to this dual representation of ICR-code there are two different kinds of ICR-interpreters. The first 
and simpler kind needs numerically represented operators, while the second kind also allows using 
mnemonics. This second kind, called MNEMONICAL-ICR-interpreter, may also be interpreted as a kind 
of preprocessor to convert mnemonics into numerical values which are reprocessed by a simple ICR- 
interpreter of the first form. 

5 Basic concepts 



5.1. Introduction 



ISO/TR 10562 is part of a series of international standards dealing with the requirements of manipulating 
industrial robots. Other documents cover such topics as safety, general characteristics, performance 
criteria and related testing methods, terminology, and mechanic^ interfaces. It is noted that these 
standards are interrelated and also related to other International Standards. 

This Technical Report describes a second committee draft for an intermediate code ICR between off-line 
programming and different robot control units. There are various levels for the representation of robot 
programming languages. ICR allows the interchange of technological and geometrical data between robot 
control units also. This does not mean, that other levels of intermediate code are inhibited. This proposal 
doesn't eliminate another intermediate code between ICR and robot control units. Nevertheless, ICR 
should be used as a standardized neutral interface between robot programming and robot control units. 

Annex A of this Technical Report provides guidance to the robot system state variables, defined in 
ISO/IEC 9506-3 "Industrial automation systems - Manufacturing specification - Part 3: Companion 
standard for robotics", which are referred to in ICR. 

Annex B of this Technical Report provides information on how to use and implement ICR at the 
application and how to come from a robot programming language to ICR code. 

A manipulating industrial robot has to perform various tasks. The set of motions and auxiliary function 
instructions which define a specific intended task of the robot system is specified by a task program. 

A given application is specified in terms of task description, or in terms of program, which is written in a 
user-oriented progranmiing language. The syntax and semantic of this user-oriented high-level 
progranmxing language depends on the type of system progranuning, e.g. declarative programming, 
CAD-oriented interactive progranmiing. The program has to be translated into the low level program code 
of the robot and then loaded into the robot control unit which will execute it. 

According to the number of various robot controllers, and to the evolution of user-oriented high-level 
progranmiing systems, it is necessary to build a bridge between both kinds of languages. 

Such a gateway is called ICR (Intermediate Code for Robots). Its goal is to support all the features that a 
robot control usually performs and all the elements to describe a task. 

The ICR code is useable to exchange user programs and data between different robot control units and/or 
between any robot programming system and control. The code itself consists of a sequence of records 
representing different instructions. Such an instruction may be a data or type definition also. The 
instructions include arithmetic and stack operations, which allow an efficient calculation of arithmetic 
expressions with respect to a postfix notation. 
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The block structure of a high-level programming language is supported which helps for structured 
programming. Variables or other programming objects are identified by symbols with respect to their 
scope in the block structure. For some special use, absolute addresses may be used, e.g. to handle memory 
mapped I/O directly. 

The proposal shows the scope of work and the functions of ICR in detail, but the formal description is 
performed on syntax resp. mnemotechnical level. The definition of code numbers is an easy mapping to 
the ICR elements described in this paper. 

Some of the used items like pose or orientation are not explained in detail. Their meaning is described in 
other ISO documents. 

The main features of the intermediate code are as follows: 

- Intermediate codes: The position of the code is the standard output format from the robot programming 
systems and the standard input format to the robot control units as illustrated in figure 1, 



user oriented 
high level 
robot 

prograinining 
language 



V 



robot 

programming 

system 




ICR 



robot 
control 
unit 1 



V 



no way return 
(except data lists) 

I ICR 



industrial 
robot 



< > 

data 
list 
ex- 
change 



robot 

control 

unit 2 



Figure 1 - Structure of robot programming with neutral interfaces 
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- The standard format for data exchange: Data list written in ICR can be used for data exchange and for 

input data of teaching-by-showing. 

- Machine-machine interface: ICR is designed as data exchange format between computer systems. As it 

is not a user-oriented language, the codes can be represented basically by integer only. However, it 
uses symbols for variables and others to improve the readability of the program. Printable character set 
is used in ICR. 

Both data and program written in ICR are transferred among the systems in figure 1. The Program is 
executed in the following two ways: 

- a program written in ICR is once converted into that in a user-specified code by means of a translator, 

and the converted program is transferred to the robot control unit. 

- the program written in ICR is transferred to the robot control unit in file or through a communication 

line, and is directly executed on the robot control unit. 

The system configuration and the implementation of a robot control unit is fully dependent on the system 
developer of the robot. In this Technical Report, however, the robot control unit is assumed to have the 
structure indicated in figure 2. 

- path generator: it computes the trajectory of the industrial manipulator. 

- servo system: it realizes the path through servo system. 

- peripheral controller: it controls digital/analog input/output units. 

- sensors: no specified devices are defined. Instead, general DIO is assumed. 

- communication line: a serial line such as RS232C is assumed. 

- file storage system: files can be used as option. 

robot control unit 

I 

path generator 

I 

servo system joints 

-- peripheral controller 

I 

sensors 

communication line 

I 

file storage system 

Figure 2 - Configuration of a robot control unit 

As for an industrial manipulator, an articulated robot with 6 degrees of freedom is assumed. Any robot 
with redundant degrees of freedom is not covered by this Technical Report. When a robot with less than 6 
degrees of freedom is used, it is defined in the same manner as well. 

5.2 Description of ICR grammar 

At the lexical level, an ICR program consists of a sequence of characters of the ISO 8859-1 (8-bit 
character set) norm. All control characters (such as a linefeed or a carriage return) are ignored in 
processing. 
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5.2.1 Metalanguage of ICR 



The ^talanguagp for the lexical definition of ICR is derived from the BNF notation; 

- terminal symbols (here characters) are enclosed in quotation marks ('); 

- parentheses '(' and y are used to show grouping; 

- concatenation is indicated by the juxtaposition of (terminal or non-terminal) symbols; 

- optional symbols are indicated by the square brackets '[' and 7; 

- repetition is indicated by the braces *{' and *}'; 

fiteml} means: iteml occurs not, one time, two times, ... , 
or n-times 

- alternation is indicated by the stroke ' | ' 

iteml I item2 means: iteml or item2 but not both 

Example: 

nuinfoer_constant : : = ' # ' ( integer | real ) , 

A number constant can be #30 to define the integer 30 or #0.3E2 to define 

the real number 30.0. 
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5.2.2 ICR lexical elements 



The syntax in this clause describes the formation of lexical elements out of characters and the separation 
of these elements from each other. Therefore, the syntax is not of the same kind as that used in the rest of 
this standard. That means, the ICR lexical elements differ from the syntactical definition because no space 
character is allowed between the terminal symbols of a repetition, e.g. the definition of an integer. The 
lexical elements will be referenced by the syntactical definitions in the following chapters. 



digit 



0' 
'5' 



1 
6 



'2 
•7 



.3, 
•8" 



4 
9' 



'B' 


'C 


'D' 


■E' 


,p, 


'G' 


'I' 


•J' 


•K' 


•L' 


•M' 


'N' 


■ p. 


•Q' 


'R' 


'S" 


,rp. 


'U' 


'W 


'X' 


'Y' 


•Z' 







upper_case_letter 
'A' 
'H' 
'O' 

'V 

lower_case_letter 
'a' 
'h' 
'o' 

'V' 

letter ::= upper_case_letter 
space : : = ' ' . 
underscore : := '_' . 
special_characterO 



•b' 


'C 


•d' 


'e' 


'f 


•g- 


•i' 


'J' 


•k' 


'1' 


'm' 


'n' 


'P' 


'q' 


•r' 


•s' 


•f 


'u' 


'W 


"X' 


•y. 


' z' 







lower_case_letter 






•&: I 



I '/ 



special_characterl 



'<v 



>• 



I •;) I 



special_character2 : 

special_character3 : 
' {' I ' I ' I •> ■ 



^ I 



graphic„character : := 

letter | digit | space 

special_characterO 

special__character2 



underscore ] 
special_characterl 
special„character3 



unsigned_integer ::= digit { digit } 
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The semantic of the data types integer, character, real, boolean, and string is described in subclause 6.2. 

integer ::= [ ( '+' | '-' ) ] unsigned_integer . 

character : : = 

' • ' graphic__character ' ' ' | 
' $ ' unsigned_integer . 

In the description of character, dollar mark '$' is used to describe the character code number. The type of 
die character code number is the ISO 8-bits code 8859-1. 

real ::= integer '.' [unsigned_integer] ['E' integer] . 

boolean ::= 'T' | 'TRUE' | 'F' | 'FALSE' . 

A string is a series of graphic characters surrounded by double quotation marks ' " '. To include a double 
quotation mark itself in a string, a concatenation of double quotation marks is used such as "abc""def ' 
standing for abc"def. 

string ::='"' {graphic„character} ' " ' . 

A symbol is formed similar to a string with no restriction on its length in which all characters are either 
letters, digits or underscore and the first character is a letter. There is no difference between small and 
capital letters (i.e. ABC and abc refer the same object). A symbol is not surrounded by double quotation 
marks. 

symbol ::= letter { ( letter | digit | underscore ) } . 



5.3 Address modes 



5.3.1 Absolute addresses 

When users need to specify absolute addresses of robot control units and other peripherals, they can use 
integer numbers which means absolute addresses of the devices. The addresses should be accepted by the 
robot control unit. Note that the interpretation of the absolute address is completely system dependent. 
Therefore users are strongly requested not to use the absolute addresses in order to make the codes 
portable. 

As mentioned already, the computational environment of a robot control unit is out of the scope of this 
standard. However, we often need to have the image of the memory space, e.g. I/O mapped peripherals, 
because ICR is a simple, and rather primitive language. Note that the "absolute addresses" are not in 
every case real addresses, but virtual addresses of the virtual memory space of the CPU. Its data type is 
positive INTEGER with no restrictions except the range of INTEGER type. It can be denoted as 

absolute_address : := '@* unsigned_integer . 

where unsignedjnteger represents the address of virtual memory space. 

Due to very high robot control system dependency the usage of absolute addresses should be avoided. 
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5.3,2 Block relative addresses 



A block relative address refers to a variable which is declared for a program block and its inner blocks 
only. If the block relative address is given by an integer, its value is calculated by the definition formula 

22'^*block_nesting_number -t- variable_index 

(Remark: The number 2^4 was defined with res[5ect to a representation of a block relative address by an 
integer of 32 bits). The block_nesting_number refers to an identical number of block nesting given in the 
block begin statement (BLKBEG) of a block activated before. If several blocks with the same number of 
block nesting are activated simultaneously, the block that was activated at last is assumed. The block 
nesting number starts with zero for the main program. 

The variablejndex refers to an identical block relative index of a variable declared by a declaration of 
variable statement (DECLVAR) inside the block referred to by the block_nesting_number. 

If a block relative address is given by its symbol, the outer block or procedure name is noted as a prefix 
with a point, e.g. procedure_out.variable_name. lif no block or procedure name is written, the inner block 
is assumed. 

blackrel_address : := 

'BRADR' ' ( ' (integer | [ symbol ' . ' ] symbol) ' ) ' . 



5.3.3 Access to operands 

In ICR instructions, the access to operands is performed by using constants, absolute or block relative 

addresses, or symbols. 

operand : : - 

symbol | absolute_address | constant | blockrel_address . 

Part of the operands are pushed on the stack and the rest of them are described in the statements. The 
results of the execution of instructions are pushed on the stack, if any. When a symbol appears, it is 
evaluated as a label, a procedure name, or a variable, according to the definition of the instruction. 

Constants of integer type are denoted by "#1012", where '#' is ASCII character. "#1012" is the decimal 
number of one thousand and twelve. 

To indicate the data pushed on and popped from the stack, the following notation is used in the definition 
of each instruction: 

Stack: 

I_n : var_type , .... , I_2 : var_.type , I_l : var__type 
-> 0_m: var_type, .... , 0_2 : var_type , 0_l:var_type 

where I_x indicates an x-th input value and 0_x indicates an x-th output value, and var_type means the 
type of data. 



10 
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The stack is "Last In First Out (LIFO)" memory and the orders of input/output values are illustrated in 
figure 3. Therefore, I_l and 0_1 is located on the top of the stack (TOS). 



TOS -->| I„l I 



I n 



TOS 


->l 


o_i 1 


> 


0_2 1 






0_m 1 



Figure 3 - Execution of stack operation 

"Var_type" can be one or more data type names (see "Variables and constants"). When two or more data 
types are accepted, express them with a pair of parentheses and a vertical stroke as shown in the following 
way: 

I_l : (var_typel | var_type2) . 

This notation is out of the lexical definition of ICR, and is only used for the explanation and description 

of the functionality. 



5.4 Structure of ICR units 

The basic structure of an ICR program consists of units. A unit may include a user program, that can also 
be a module containing procedures and functions, or a data list including data. Modules are needed to 
develop program parts separately and link them together. Data lists can be used to exchange data from 
one robot control unit to another, e.g. the positions for a user program. 

icr_unit : :- program | data_list . 
program ::- pbeg { statement } pend . 
data__list ::= dlhead { dldat } dlend , 



5.5 Statement structure 



Every operation expressed by ICR is written as a statement consisting of a line number and an instruction. 
An instruction consists of an operator and zero, one or more operand(s). The operands are separated by a 
comma and the operation is closed by a semicolon. 



11 



IS 15035 : 2001 
ISO/TR 10562 : 1995 



All operators are represented by code numbers which are expressed by ASCII-character digits, e.g. 
'22100'. For the readability of code description, the operators can also be denoted by mnemonics, for 
example 'PBEG'. Line numbers have to be unique. 

statement : := line_number ' , ' instruction ' ; ' . 
line_number ::= unsigned_integer . 

instruction : : = 

remark | declvar | typedef | progflow | operation | 

specification | movecontrol | dataexchange | 

datalistop | description | sensor function | debugf unction 

Instructions are defined in chapter 7, but for convenience, one example is shown: 

remark : :- cd_remark ' , ' linenumber ' , ' text . 
cd_remark ::= 'REMARK' | remark_code . 

remark_code = 1000 (integer) 

linenumber = linenumber of the high level robot 

programming language (integer) 
text = remark (string) 

where cd„remark means code of the REMARK instruction, either the mnemonic 'REMARK' or 1000, the 
instruction code number for REMARK. Both representations (mnemonics and numerical codes) improve 
the definition of two classes of conformance for the ICR loader: conformance class 1 adopts codes only, 
and conformance class 2 adopts codes and mnemonics. "Linenumber" and "text" are the operands of the 
REMARK instruction. 



5.6 Program flow structure 

As ICR is designed as intermediate code between two computer systems, it does not include complicated 
program flow structures. Instead, a simple and quick mechanism is introduced such as unconditional 
branch and conditional branch. 

All statements are numbered by serial instruction number which is represented in unsigned integer. The 
destination of the branch is defined by the serial instruction number, thus 

label ::= unsigned^integer . 

It is prohibited to jump into the blocks or procedures from the outside of them. 

Block structure is introduced in ICR. In a block, dynamic variables can be used, which must be declared 
at the head- of the block "blkbeg" and are cancelled when the program flow exits from the block. Nesting 
and other feature of the block are designed in the same manner as those in Pascal. 



12 
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6 Data types 

6.1 Data pro(}essing in ICR 

ICR is a code system which computes data in memory, gets information through peripherals and sensors, 
and controls peripherals and industrial manipulators. Numerical calculation is executed on a stack. 

The definition of ICR doesn't include any restriction on memory addressing or scope rules or nesting of 
procedures and functions. Any restriction caused by implementation must be conmiunicated to users. 



6.1.1 Data types 

Data types defined in ICR are classified into 

- logical and arithmetic data types: integer. Boolean, real, character 

- text data types: string 

- structured data types: array, record 

- geometrical data types: position, orientation, pose 

- robot dependent data types: joint, main Joint, addjoint, robtarget 

The details will be given in subclauses 6.2 to 6.5. Except for the latter four data types, all the other data 
types have the equivalent data structure in Pascal. Implementation of data structure is system dependent. 
The latter four types are specially prepared for robot control. 

As the mixed computation among different data types is basically prohibited, operations are prepared for 
each data type and their combinations. Castings of data types are also prepared. 



6,1.2 Variables 



ICR has two kinds of variables: 

- static variable 

- dynamic variable 

The latter can be used inside of blocks and procedures only. 

A variable is represented either by a unique symbol that is declared before use or a variable can be 
accessed by block relative addressing. 

The type of a variable is given by its identifier, which can be a code number or a symbolic name, see the 
table later on. 

var_type ; := type_identif ier | data_type . 
type_identif ier : := unsigned__integer . 
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data__type : : = 

'BRADR' I 'INT' i 'REAL' | 'BOOL' | 'CHAR' | ' STR ' | 

' POS ' I ' ORI ' I ' POSE ' I ' JOINT ' | ' M_JOINT ' j ' A__JOINT ' | 

' ROBTRT ' 

Abbreviations of data types are fully described in subclause 7.4. 

Table - Predefined data types in ICR 



type^identifier data_type data type 



BRADR block relative address 



INT integer 



REAL real 



BOOL boolean 



CHAR character 



STR string 



(reserved) (reserved) 



(reserved) (reserved) 



POS position 



ORI orientation 



10 POSE pose 



11 JOINT point 



12 MJOINT main_„joint 



13 A_JOINT add_joint 



14 ROBTRT robtarget 



The data types of the ICR are divided into the following groups: 

* logic and arithmetic data types 

They are used for logic and arithmetic calculations like in traditional computer science. 

* text representation 

The data type STRING allow to handle text information, e.g. to react on user terminal input or to 
built-up messages by text blocks. 

* structured data types 

Similar to Pascal the user can define structured data types. 

* robot independent geometrical data types 

For defining the move of a robot it is very useful to have geometrical data types, which are 
predefined structured data types. The robot position can be described by POSITION (cartesian 
coordinates). The robot orientation resp. the end effector orientation can be given by 
ORIENTATION (cartesian reference coordinate system). A POSE describes the robot position and 
orientation in cartesian coordinates only. 

* robot dependent geometrical data types 

The robot dependent data types can differ from one robot (more precise: robot kinematics) to another. 
Therefore they are implementation dependent and their definition must be changed, if the ICR- 
program is transferred from one robot control to another. The axis coordinates are expressed by the 
data type JOINT. ROBTARGET describes the robot position and orientation in cartesian coordinates 
like a POSE, but it includes configuration information, used in ambiguous positions, and joint values 
for additional axis if it is needed. 

All datatypes described above are predefined. 
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6.2 Logical and arithmetic data types 

For each data type below, a type definition will describe the predefined values which the data type could 
take. The syntax was defined in subclause 5.2.2. 

BOOLEAN (BOOL) 

A data type covering the logical values TRUE' and 'FALSE'. 

Permitted values are: 

false_value= FALSE I F 
true_value = TRUE IT 

INTEGER (INT) 

A data type covering a range of integers. 

Permitted values are within a range of integer values where: 

lowerJnteger_value = -2 147 483 647 

higher_integer_value= +2 147 483 647 
(The value of an integer variable is represented by a 32-bit word) 

CHARACTER (CHAR) 

A data type holding exactly one ASCII character. 

Permitted values are: 

graphic_character ! range_of _unsigned_integer 

range_of_unsigned_character = to 255 
The first 128 values correspond to the ASCII-code. 

REAL (REAL) 

A data type covering a range of real numbers. 

Real number: 

real_value : := integer ' . ' [unsigned_integer] [exponent] . 

exponent : : = ' E ' integer . 

A real number is expressed in the conventional notation consisting of a mantissa, and an optional 
exponent. 

The mantissa consists of a positive, null or negative integer value, followed by a mandatory period 
'.', and optionally by an unsigned integer value expressing the decimal part of the mantissa. 

The exponent is a positive, null or negative integer value which represents a power of ten. 

No space is allowed within the definition of a real number. 

Permitted values are real values within two ranges and true_zero where: 
negative_range = -1.7E38 to -L7E-38 
positive_range = 1.7E-38 to 1.7E38 
true zero = 0. 
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(The value of a real variable is represented by a 32-bit floating point, see also IEEE 754) 

BRADR (BRADR) 

A data type covering a block relative address. 

Permitted values are within a range of integer values where: 

]owest_bradr_value = 

highest_bradr_value = + 4 294 967 296 
(A block relative address value is represented by a 32-bit word) 

These ranges are minimum requirements for each ICR implementation. 



6.3 Text representation 



STRING (STR) 

A data type consisting of a number of characters enclosed by double quotes ' " * and containing 
information about the actual length of the string. The index of a character in the string starts with 
1, the possible length must be at least 255. 



6*4 Structured data types 

There is no explicite data type for structured data types like arrays or records in ICR. Nevertheless it is 
possible to define arrays in ICR and operate on them by an efficient block relative address administration. 

An example should illustrate this. Some ICR-elements used in this example are explained in detail later 
on. In a potential high level language the following data definitions and assignment arc specified: 



VAR 

X: RECORD 

K_l:real 



K_2: integer; 

K_3: array [1 ..5] of integer; 

K_4: array [1 .. 4] of 



RECORD 

L_l: real; 
L_2: integer; 
ENDRECORD; 
ENDRECORD; 
Y: integer; 



BEGIN 

Y := X.K_4[3].L_2; 
ENDPROG. 
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The type declaration can be done as follows: 

snr, TYPEDEF. 4096, 1, REAL, 1, INT; 

snr, DECLVAR, 0, 1, REAL, 0, 6, INT, 0, 4, 4096, 0, 1, INT; 

To access the array components for the assignment the following address management by ICR is 
necessary: 

Let 3 be the block relative address of "X": 

Block relative address of component "X.K_4" -> TOSq: 
snr, PUSHBR, BRADR(IO); 

Number of inner record components -> TOS { : 

snr, PUSHSZ, 4096; number of components 

(L_1,L_2) 

Index minus lower bound -> TOS2: 

snr, PUSHI, #3; 

snr,PUSHI,#l; 

snr, SUBI; 
(all 3 lines could be optimized to: "snr, PUSHI, #2") 

Check that index is not too large: 

snr, PUSHI, #3; TOS3 <- (upb-lwb=4-l=3) 

snr, CHECK_BR, error_snr, 0; 

Compute address of indexed element: 

snr, MULBR; TOS 1 <- TOS2 * TOS 1 
snr, ADDER; TOSq <- TOSi + TOSq 

Compute address of record field "L_2" -> TOSq: 

snr, ADD_DIST, BRADR(IO), BRADR(1 1); 

Fetch value and store into variable "Y": 

snr, LOADVD, 1 ; TOSq <- integer value 

in X.K_4[3].L„2 
snr,POPI,BRADR(18); 



6.5 Predefined geometrical data types 



POSITION (POS) 

The structured data type for defining the robot position contains 3 real numbers: 

RECORD X , Y , Z : REAL ; END 
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ORIENTATION (ORI) 

The structured data type for defining the robot resp. end effector orientation with respect to a 
cartesian coordinate system consists of an integer for indicating the kind of orientation definition 
and 4 real numbers for the value of orientation (angles or other parameters). The identifier for the 
kind of orientation definition is used to select the meaning of the 4 reals: 
RECORD 

ori„id : INT; 
a , b , c , d : REAL ; 
END 

Examples may be: 

ori_id = 1 

a, b, c are rotation angles around the x-, y- and z-coordinate axes, d can be any value. 
ori_id = 2 

a, b, c are rotation angles around the z-, y'- and z"-coordinate axes, d can be any value. 
ori_id = 3 

a, b, c are rotation angles around the z-, y'- and x"-coordinate axes, d can be any value. 
ori_id = 4 

a, b, c are rotation angles around the y-, x'- and z"-coordinate axes, d can be any value. 
ori_id = 5 

a, b and c are the normalized vector coordinates (for x- and y-direction, and z-axis) of the 

center of rotation. The component d is the rotation angle. 
ori_id = 6 

a, b, c, d are parameters of the quaternion specification. 

POSE (POSE) 

A pose consists of the position and orientation definition of a cartesian system; 

RECORD 

POSITION : POS; 

ORIENTATION : ORI ; 
END 

ROBTARGET (ROBTRT) 

A structured data type for describing a robot move target and different parameters: 

RECORD 

cartpos : POSE; 

{* cartesian position *) 

(* and orientation *) 
status : INT; 

(* information about additional *) 

{* degree of freedom *) 
turns : ARRAY [ 1 . . r_nturns ] of INT; 

(* number of rotations of 360 degrees *) 
adax : ADJOINT; 

(* joint position for *) 

{* additional axes *) 
END; {* RECORD *) 

Status describes an additional degree of freedom (for example 'shoulder right or left'). The relation 

between values of data type integer and the robot configuration is system dependent. 

Turns describes the number of rotations of 360 degrees performed by some axes. R_ntums defines 

the number of joints, which can rotate more than 360 degrees. R^nturns is robot dependent and 

fixed and must be known by both the programming system and the robot control system 

(systemparameter). 
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Because the number of the additional axes are robot dependent there is a variant record, A_JOINT, 
for defining these axis. 

JOINT (JOINT) 

A structured data type for describing a robot destination in joint coordinates. Because the number 
of axes is robot dependent, joint is composed by the variant records M_JOINT and A_JOINT, to 
distinguish between main axes and additional axes. 

RECORD 

jointpos : M_JOINT; 

{* joint position for the *) 
(* main robot axes*) 
adax : A_ JOINT ; 

(* joint position for the*) 
(* additional axes *) 
END; (* RECORD *) 

MAINJOINT (M_JOINT) 

A structured data type for describing the robot axes in joint coordinates. The data type consists of 
a number of robot axis values of type REAL. The number of robot axes is robot dependent and 
fixed and must be known by both the programming system and the robot control system. The 
number of axes is defined by a system parameter in the control system. According to the axis type, 
the components are either angles (rotational axis) or distances (translational axis). At the 
beginning of a program the number of axes can be checked with the CHECK- AXES instruction. 

RECORD 

A„1,A„2 : REAL; 

END; 

ADD.JOINT (A_JOINT) 

A structured data type for describing the additional axes in joint coordinates. The data type 
consists of a number of axis values of type REAL. The number of additional axes is robot 
dependent and fixed and must be known by both the programming system and the robot control 
system. The number of additional axes is defined by a system parameter in the control system. 
According to the axis type, the components are either angles (rotational axis) or distances 
(translational axis). At the beginning of a program the number of additional axes can be checked 
with the CHECK- AXES instruction. 

RECORD 

AA_1,AA_2, : REAL; 

END; 



Example: 

Assumed an industrial robot has five main axes and two additional axes. 
Then the data type M JOINT is composed by five reals: 

RECORD 

A_l , A_2 , A_3 , A_4 , A_5 : REAL ; 
END; 
The the data type A_JOINT is composed by two reals: 

RECORD 

AA_1,AA_2 : REAL; 
END; 
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And the data type JOINT is composed by MJOINT and A_JOINT: 

RECORD 

jointpos : M_JOINT; 

adax : A_ JOINT; 

END; 



6.6 Constants 

Constants are denoted by the following definitions: 

constant ::= simple_constant | structured_constant , 

nuinber_constant ::= '#' (integer \ real) . 

simple_constant ::= \ ^ • ^ 

'#• (integer | real | boolean | character | string) . 

structured_constant : := 

• # • ■ ( ' type„identif ier ' , ' 
data_structure_def inition ' ) ' . 

data_structure_definition ::= 

position_cons | orientation_cons | pose_cons | 
j oint„cons \ robtarget_cons . 

position_cons : := 

number_constant ' , ' nuinber_constant ' , ' 
nuinber_constant . 

orientation_cons : := ^ . , 

integer ' , ' nuinber_constant ' , ' nuinber_constant , 
number_constant ' , ' nuinber_constant . 

pose_cons : := i. 4. 4- 

number„constant ' , ' nuinber_constant ' , ' number„constant 
' , ' integer ' , ' nuinber„constant ' , ' nuinber__constant ' , 
number_constant ' , ' number_constant . 

joint_cons : : = 

main_joint_cons ' , ' add_joint„cons , 

main_j oint_cons : : = 

nuinber_.constant ' , ' ... ' , ' number_constant . 

add_joint_cons : := 

number_constant ' , ' ... ' , ' nuinber„constant . 



robtarget^cons : := 

pose_cons ' , ' integer 
integer ' , ' ... ' , ' integer 
add„joint_cons . 



I I 

/ 

I I 
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7 Instructions 



ICR consists of a number of instructions, which are ordered by the following groups: 

- house-keeping information 

These instructions may be used for transferring additional information to the robot control or 
especially test facilities. Examples are line numbers and the designation of the user program 
statements. 

- memory and data management 

Instructions for loading and storing of variables and memory allocation. 

- program flow control 

To control program execution these instructions include subroutine management, branches, loops and 
other elements. 

- Boolean and arithmetic operations 

These instructions include the boolean and arithmetic operations as they are known by high level 
programming languages. Additionally arithmetic operations for the geometrical data types are 
provided, e.g. position transformation by a rotation. 

- technical specifications 

Especially for the industrial robot move control technical specifications are needed, e.g. velocity, 
acceleration, or move time. 

- move and end effector control 

These instructions allow the description of robot moves and end effector operations. 

- interchange of data 

Instructions Statements for conmiunication with peripheral devices, operator panels or process 
control. 

- data list management 

These instructions statements are for managing external data lists, e.g. including robot positions. 
They allow operations like read and write list elements, open and close the list file and others. 

- description of robot facilities 

There are instructions for limitation of working space, robot kinematics, tool description, units of 
measurements, length and angles, scaling factors and others. 

- end effector control (not included, future extension) 

Instructions for end effector (gripper, tools, manufacturing devices) control. 

- sensor functions (not included, future extension) 

Instructions for sensor specification and control. 

- concurrent programming (not included, future extension) 

Program elements for task declaration, execution, delay, priorities, and cancelation. Synchronization 
of tasks or with external events. 

- debugging functions (beginning, future extensions) 

Commands for testing and special service information, that are not part of a user program in ICR. 



21 



IS 15035 : 2001 
ISO/TR 10562 : 1995 



user specific extensions 
The user may specify his own application specific instructions by special instruction notation. 

future extensions 
Code reserved for future extensions. 



7.1 House*keeping information (REMARK) 

This instruction can be used for including remarks identifying the line number in the source program or 
any other textual information (can be removed during compilation or code loading on control). 

Group of compliance: group A, level 

Syntax: 

remark ; := cd„remark ' , ' linenumber ' , * text . 
cd„remark : := 'REMARK' | remark__code . 

r emark_code = 1 ( integer ) 

linenumber = linenumber of the high level robot 

programming language ( integer ) 
text = remark (string) 



7.2 Memory and data management 

7.2.1 Declaration of variables (DECLVAR) 

Every global or local variable must be declared. The variables are declared by the number of objects and 
their data type or by their symbolic name and their data type. The actual address of the variable must not 
be specified. 

The block relative indices are given in consecutive increasing order beginning with 0. For structured 
objects (as well for TYPEDEF objects with a typecode greater than 4095, as for predefined objects) one 
block relative index is associated for each elementary object, e.g. for four POSITION objects (..,4,8,..) 12 
indices are associated. The order of the indices is the same as the order of the object declarations through 
all DECLVAR statements since the last BLKBEG. 

Group of compliance: group A, level 
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Syntax: 

declvar : : = 

cd_declvar ' , ' indicator ' , ' ( (number_of_objects ' , 
var_type) | (symbol ',' var_type) ) { ',' indicator 
' , ' ( (number_of_objects ' , ' var_type) | (symbol ' , ' 
var_type) ) } . 

cd_declvar : := 'DECLVAR' | declvar_code 

indicator : : = ' ' | ' 1 ' . 

var_type :;= data_type | type_identif ier | symbol 



declvar_code 
indicator 



number_of _ob j ects 

var__type 
symbol 



500 (integer) 

indicator for gobal (static) or local 

variable ( integer ) 

= gobal 

(for block nesting equals tc 0) 

1 = local 

(for block nesting greater than 0) 
niimber of variables of the specified 
type (integer) 
type of the variable 
name of the variable (string) 



7.2.2 Type definition (TYPEDEF) 



This statement can be used for defining compound data types. The hereby declared data types can be 
composed of predefined data types and data types defined by preceding type definition. 

Group of compliance: group A, level 
Syntax: 

typedef : : = 

cd_typedef ' , ' ( type_identif ier | symbol ) ' , ' 

number_of_components ' , ' comp_type 

{ ' , • number_of_components ' , ' comp_type} , 
cd_typedef : : = ' TYPEDEF ' | typedef_code . 



typedef_code 
type_identif ier 

symbol 

number_o f _c omponen t s 

comp__type 



700 (integer) 

identifier of the declared type 

(integer >= 4096 ) 

name of the type (string) 

number of components of the 

specified type (integer) 

component data type descriptor 

(integer) 



In programming languages type definitions are originally "pseudo codes". Such codes are usually not 
included in executable code. Due to this understanding ICR may be taken as the transfer representation of 
source text, not as executable code. These type definitions can also be handled, this means being changed 
to basic data types, by a preprocessor or a program loader. 
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7.3 Program flow control 



These instructions are used to control the execution and the timing of a program. They also include 
statements for the program and subroutine management. 



Syntax: 

progf lov; 



pbeg I pend 
jump_target label 
if I jmp_dec | noop 
pause I teachon. 



check_axes | check_ori | check__br 



subpend | blkbeg | blkend 



call 
goto 



delay | wait_b j wait_le | wait_ge 



7.3.1 Program begin (PBEG) 

The beginning of a program. This is the first statement of a program. 

Group of compliance: group A, level 

Syntax: 

pbeg : := cd_pbeg ' , ' f irst_nuinber ' , ' name. 
cd_pbeg : : = ' PBEG ' | pbeg_code 

pbeg_code = 22100 (integer) 

first_number = number of the first instruction of the 

programm block (integer) 
name = name of the program (string) 



7.3.2 Program end (PEND) 

The end of a program. This is the last statement of a program. The program execution stops. 

Group of compliance: group A, level 

Syntax: 

pend ::= cd_pend. 

cd_jpend : : = ' PEND ' | pend_code . 

pend_code = 22150 (integer) 
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7.3.3 Check.axes (CHECK_AXES) 



Check the number of axes and the number of additional axes. At the beginning of a program each 
controller can check if the number of axes and the number of additional axes in this program correspond 
to the number of axes of the robot and to the number of additional axes. The boolean result is put on the 
top of the stack. 

Group of compliance: group A, level 

Syntax: 

check_axes : : = cd_check_axes ' , ' ax^number ' , ' 

add_ax_nuinber . 
cd__check_axes : : = ' CHECK_AXES ' | check_axes_code . 

check_axes_code = 22850 { integer ) 

ax_nuinber = number of robot axes (integer) 

add_ax_number = number of additional axes (integer) 



7.3.4 Check_ori (CHECK_ORI) 

Check the orientation description. At the beginning of a program each controller can check if the 
orientation description used in this program corresponds to the implemented orientation description of the 
controller. The boolean result is put on the top of the stack. If several orientation identifiers are used in a 
program, a check should be done for each orientation identifier. 

Group of compliance: group A, level 

Syntax: 

check_ori : : = cd_check_ori ' , ' ori_id . 

cd__check_ori : : = ' CHECK_ORI ' | check_ori_code . 

check_ori_code = 22860 (integer) 

ori_id = orientation identifier (integer) 



7.3.5 Check value on top of stack (CHECK_BR) 

If the integer value on the top of stack- 1 is greater than the value on top of stack, the program execution 
continues at the instruction defined by instruction_number. The value on top of stack is removed, the 
value on top of stack- 1 is not removed. 

Group of compliance: group A, level 
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Syntax: 

check__br : : = check_br_nr | check_br_syin 

check_br_nr ::= cd_check_br„nr ',' instruction.number 

• , • block__nesting„dif ference . 
cd_check„br_nr ::= ' CHECK_BR_NR ' 1 check_br_nr„code . 

check br_nr_code = 22870 (integer) 
instruction_number = instruction number of the target 

(integer) 
block nesting difference = target block nesting level minus 

actual block nesting level 

(integer) 

check_br_sym ::= cd_check_br„sym ',' symbol 

• , ' block_nesting„dif f erence . 
cd_check_br_sym ::= ' CHECK_BR„SYM ' | check_br.sym_code . 

check br sym„code = 22880 (integer) 

symbol " = label name of the target 

(string) 
block nesting_dif ference = target block nesting level minus 

actual block nesting level 

(integer) 



7.3.6 Procedure call (CALL) 

The call of a procedure. 

The procedure call can be done by using the serial instruction number of the procedure or by a symbol 
(name of the procedure). 

The parameters are passed over the stack. 

Group of compliance: group A, level 
Syntax: 

call ::= cd„call ',' subbeg_number . 
cd_call ::= 'CALL' | call_code . 

call_code = 22200 (integer) ^ 

subbeg_number = instruction number of the first executable 

statement of the procedure (integer) 
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7.3.7 Subroutine begin or target for a jump (LABEL) 



The beginning of a subroutine or a target. The parameters are passed by the stack. The last parameter of a 
procedure call should be on the top of the stack. 

Group of compliance: group A, level 
Syntax: 

jump_target ::= cd_juinp_target ',' symbol. 

cd_jump_target ::= 'LABEL' | jump_target_code . 

jump__target_code = 22400 (integer) 



7J.8 Subroutine end (SUBPEND) 



The end of a subroutine. This is the last statement of a subroutine. A return after the subroutine call 
statement is executed. 

Group of compliance: group A, level 
Syntax: 

subpend : : = cd_subpend . 

cd_subpend : : = ' SUBPEND ' | subpend_code . 

subpend_code - 22220 (integer) 



7.3.9 Block begin (BLKBEG) 

The beginning of a block. The storage for data objects is prepared. A block is used to restrict the scope of 
data objects (as defined in a high level robot prograihming language, e.g. including a Pascal-like data 
concept) and to manage their memory allocation. Especially for procedures and subroutines the block 
declaration is useful. 

Group of compliance: group A, level 

Syntax: 

blkbeg : := cd_blkbeg ' , ' block_num ' , ' block_nest . 
cd_blkbeg ::= 'BLKBEG' | blkbeg_code . 

blkbeg_code = 22300 (integer) 

block__num = block number (for testing) (integer) 

block_nest = number of block nesting (integer) 
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7.3.10 Block end (BLKEND) 

The end of a block. The reserved storage for data objects is freed. 

Group of compliance: group A, level 

Syntax: 

blkend ::= cd„blkend. 

cd„blkend ::= 'BLKEND' | blkend_code. 

blkend_code :=: 22310 (integer) 

7.3.11 Unconditional program jump (GOTO) 

The program execution continues at the instruction defined by instruction_number or at the label defined 
by the LABEL instruction. 

Group of compliance: group A, level 

Syntax: 

goto ::= goto__nr | goto_symbol . 

goto_nr : := cd_goto__nr ' , ' instruction_number, 

nest_dif ference . 
cd_goto_nr : : = ' GOTONR ' | goto_nr_code . 

goto_nr_code = 22420 (integer) 

instruction_number = instruction number of the target 

(integer) 
nest__dif f erence = target block nesting level minus 

actual block nesting level 

goto_symbol : := cd_goto_symbol * , * symbol, nest_dif f erence . 

cd_goto_symbol ::= 'GOTOSYM' | goto_symbol„code . 

goto_symbol_code = 22430 (integer) 

symbol = name of the program part (string) 



7.3.12 Conditional program jump (IF) 

If the value on the top of the stack is the boolean value FALSE, the program execution continues at the 
instruction defined by instruction_number or at the label defined by the LABEL instruction. The value on 
the top of the stack is removed. 

Group of compliance: group A, level 
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Syntax: 

if ::= if_nr | if_symbol . 

if_nr : := cd_if_nr ' , ' instruction_number . 
cd„i f _nr : : = * I FNR ' | i f _nr_c ode . 

if_nr_code = 22450 (integer) 

instruction_nuniber = instruction number of the first 

instruction after the THEN_Program_part 
(if there is an ELSE_part, this will be 
the beginning of the ELSE_program_part, 
otherwise it is the statement to 
continue the program) (integer) 

if_symbol : := cd_if_symbol ' , ' symbol . 
cd_if_symbol : : = ' IFSYM ' | if_symbol_code . 

if_symbol_code = 22460 (integer) 

symbol = label name of the first instruction 

after the THEN_Program_part (if there is 
an ELSE_part, this will be the beginning 
of the ELSE_program_part, otherwise it 
is the statement to continue the 
program) (string) 



7.3.13 Jump or decrement (JMP_DEC) 

Jump on zero or decrement. The program execution continues at the label defined by the LABEL 
instruction. If the value on the top of the stack is zero, it is removed. 

Group of compliance: group A, level 

Syntax: 

jmp_dec ::= jmp_dec_nr | jmp_dec_symbol . 

jmp__dec_nr ::= cd_jmp_dec_nr *,' instruction_number . 
cd_jmp_dec„nr : : = ' JMP_DEC_NR ' | jmp_dec_nr_code . 

jmp_dec_nr_code = 22470 (integer) 

instruction_number = instruction niomber to continue the 

program in case of zero (integer) 

jmp_dec_symbol : := cd_jmp_dec_symbol ' , ' symbol . 
cd_jmp_dec„symbol : := ' JMP_DEC_SYM ' | jmp_dec_symbol_code . 

jmp_dec_symbol_code = 22480 (integer) 

symbol = label name of the program part to 

continue the program in case of 

zero (string) 
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If the integer value on the top of the stack is zero, the program execution continues at the instruction 
defined by instruction_number or at the label defined by the LABEL instruction. Otherwise the integer 
value on the top of the stack is decremented by one. 



7.3.14 No operation (NOOP) 

No operation is performed. Memory space in the ICR code area will be reserved for testing purposes. 

Group of compliance: group A, level 

Syntax: 

noop : : = cd_noop . 

cd_noop : : = ' NOOP ' | noop„code . 

noop_code = 22999 (integer) 

7.3.15 Delay (DELAY) 

Delay of the program execution. 

Group of compliance: group A, level 

Syntax: 

delay ::= cd_delay . 

cd_delay : := 'DELAY' | delay_code . 

delay_code = 22600 (integer) 

The program excecution is delayed for the time in seconds, according to a real value on the top of the 
stack. The value on the top of the stack is removed. 

7.3.16 Wait for binary input (WAIT_B) 

WAIT for binary input or jump if timeout. 

Group of compliance: group A, level 

Syntax: 

wait_b ::- wait__b__nr | wait_b_syinbol , 

wait_b__nr : := cd_wait_b_nr ' , ' instruction_nuinber . 

cd_wait_b__nr : : = ' WAIT_BNR ' | wait_b_nr_code . 

30 



IS 15035: 2001 
ISO/TR 10562 : 1995 



wait_b_nr_code = 22620 (integer) 

instruction^number = instruction number to continue the 

program in case of timeout (integer) 

wait_b„symbol ::= cd_wait_b_SYmbol ',' symbol , 
cd_wait_b_symbol ::= 'WAIT_BSYM' | wait_b_symbol_code . 

wait„b_symbol_code = 22630 (integer) 

symbol = name of the program part to continue 

the program in case of timeout 

(string) 

The program execution is delayed till the binary input is equal to the boolean value on the top of the 
stack. In case of timeout, the program execution continues at the instruction defined by 
instruction_number or symbol. There are three parameters on the stack: channeLnumber (I_3, integer), 
the boolean value (I_2), and on the top of the stack the timeout value in seconds (I_l, real). If the timeout 
value is less than zero no timeout check will be done. The values on the top of the stack are removed. 



7.3.17 Wait for analog input (less than or equal to) (WAIT^LE) 

WAIT till an analog input is less than or equal to a threshold value or jump if timeout. 

Group of compliance: group A, level 

Syntax: 

wait_le ::= wait__le_nr | wait_le_symbol , 

wait_le_nr : := cd_wait_le„nr ' , ' instruction_niimber . 
cd_wait_le_nr ::= *WAIT_LENR* | wait„le__nr_code . 

wait„le_nr_code = 22640 (integer) 

instruction_number = instruction number to continue the 

program in case of timeout (integer) 

wait_le_symbol ::= cd_wait„le_symbol ',' symbol . 
cd_wait_le_symbol : : = •WAIT_LESYM' | wait_le_sYmbol_code , 

wait_le_symbol_code = 22650 (integer) 

symbol = name of the program part to continue 

the program in case of timeout 

(string) 

The program execution is delayed till the analog input is less than or equal to the real value on the stack. 
In case of timeout, the program execution continues at the instruction defined by instruction_number or 
symbol. There are three parameters on the stack: channeLnumber (L3, integer), the real value (LJ2), and 
on the top of the stack the timeout value in seconds (LI, real). If the timeout value is less than zero no 
timeout check will be done. The values on the top of the stack are removed. 
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7.3,18 Wait for analog Input (greater than or equal to) (WAIT_GE) 

WAIT till an analog input is greater than or equal to a threshold value or jump if timeout. 

Group of compliance: group A, level 

Syntax: 

wait_ge ::= wait_ge_nr | wait„ge_syinbol . 

wait_ge_nr : := cd_wait_ge_nr ' , * instruction_niiinber . 
cd_wait_ge„nr : : = ' WAIT_GENR ' | wait_ge_nr_code . 

wait_ge_nr„code = 22660 (integer) 

instruction_number = instruction number to continue the 

program in case of timeout (integer) 

wait_ge_symbol : := cd_wait_ge_symbol * , * symbol . 
cd_wai t_ge_symbol : : = ' WAIT_GESYM ' | wait_ge_symbol_code . 

wait_ge_syinbol„code = 22670 (integer) -' '' 

symbol = name of the program part to continue 

the program in case of timeout 

(string) 

The program execution is delayed till the analog input is greater than or equal to the real value on the 
stack. In case of timeout, the program execution continues at the instruction defined by 
instruction_number or symbol. There are three parameters on the stack: channel_number (I„3, integer), 
the real value (I_2), and on the top of the stack the timeout value in seconds (I_l, real). If the timeout 
value is less than zero no timeout check will be done. The values,on the top of the stack are removed. 



7.3.19 Pause (PAUSE) 

Pause, wait for start signal. 

Group of compliance: group A, level 

Syntax: 

pause : : = cd_j)ause . 

cd_pause : : = ' PAUSE ' | pause_code . 

pause_code = 22700 (integer) 

The automatic program execution is paused and the string on the top of the stack is written to the standard 
output device. The value on the top of the stack is removed. After the start signal for "program start" the 
automatic program execution is continued. 
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7.3.20 Teach programming mode on (TEACHON) 

The automatic program execution is suspended and the teach programming mode is started. After the end 
of the teach programming mode and confirmation the program execution is continued. 

Group of compliance: group A, level 

Syntax: 

teachon : := cd_teachon. 

cd_teachon : : = ' TEACHON ' ( teachon_code . 

teachon_code = 22800 ( integer ) 



7.4 Boolean and arithmetic operations 

These instructions are used for boolean and arithmetic operations and for string and joint manipulations. 
The operands should be on the stack and the last operand is on the top of the stack. The operands are 
replaced and after the operation the result is on the top of the stack. 

Syntax: 

operation : := 

ari_opl I ari„op2 | b_opl | b_op2 | 

gen_op | s t r_op | pap_op_c | pap_opv | pap_opvf t | 

pap__opvd I pushsz I add_dist . 

The mnemonic representation of the operation codes consists of a mnemonic code for the operation, 
followed by one or two letters, indicating the data type of the used operands. Therefore the data types are 
represented by abbreviations : 
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shortest form | short form | data type | 


A 


BRADR 


block relative 
address 



B 1 


BOOL 1 


boolean | 


c 


CHAR 1 


character | 


I 


INT 1 


integer | 


R 


REAL 


real | 


P 


POS 


position 1 





ORI 


orientation | 


E 


POSE 


pose 1 


T 


ROBTRT 


robtarget | 


J 


JOINT 


joint 1 


M 


M_JOINT 


main_ joint | 


P 


1 A_JOINT 


add_ joint | 


S 


1 STR 


1 string | 



7.4.1 Arithmetic operations 



The arguments of trigonometrical functions are assumed to be in radian. In the same way the resuUs of 
inverse trigonometrical functions are in radian. 



7.4.1.1 Arithmetic operations with one operand 



Arithmetic operations with one operand are arranged in the following table. The operand should be on the 
top of the stack (exceptional TOS-1 in case of FLTMl). The operand is replaced and after the operation 
the result is on the top of the stack (exceptional TOS-1 in case of FLTMl). 

Group of compliance: group A, level 
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Syntax: 

ari_opl ::= opl__syinbol | ari_opl_code . 
opl_syinbol = 
ari_opl_code = 



symbol for the arithmetic operator 

(see table) 

code (see table) (integer) 



ari_ 
opl_ 
code 


opl_ 
sym- 
bol 


type 

of 

result 


type 

of 

oper. 


explanation 


21005 


ABSI 


INT 


INT 


absolute value of 
integer 


21010 


ABSR 


REAL 


REAL 


absolute value of 
real 



21015 NORM REAL 



POS 



norm of a vector 
(square root of 
(X*X + Y*Y + Z*Z) ) 
example: If the 
operand is the dif- 
ference of two po- 
sitions (done by 
SUBP) , then the re- 
sult is the dis- 
tance between these 
positions 



21020 I NEGI I INT 



INT 



negation of integer] 

I 



21025 1 NEGR | REAL REAL | negation of real 


21030 


NEGP 


POS 


POS 


negation of each 
component of a 
position 


21035 


ROUND 


INT 


REAL 


rounding a real to 
the nearest integer 
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ari_ 
opl_ 
code 


opl_ 
sym- 
bol 


type 

of 

result 


type 

of 

oper. 


e3q>lanatlon 


21040 


TRUNC 


INT 


REAL 


truncation of real 
to em integer 


21045 


FLOAT 


REAL 


INT 


convert the con- 
tents of TOS from 
integer to real 



21050 FLTMl REAL 



INT 



convert the con- 
tents of TOS-1 from 
integer to real 
(the contents of 
TOS is unchanged) 



21055 



ORD 



INT 



CHAR 



convert a character 
to the according 
ordinal number of 
the character set 



21060 CHR 



CHAR 



INT 



convert an ordinal 
number of the 
character set 
to the according 
character 



21065 


BOOLI 


INT 


BOOL 


convert the con- 
tents of TOS from 
booleeui to integer 


21070 


CTTJ 


JOINT 


ROBTRT 


convert the con- 
tents of TOS from 
robtarget to joint 


21075 


CTJT 


ROBTRT 


JOINT 


convert the con- 
tents of TOS from 
joint to robtarget 


21080 


SQRT 


REAL 


REAL 


square root 


21085 


SIN 


REAL 


REAL 


sine-function 


21090 


COS 


REAL 


REAL 


cosine- function 


21095 


TAN 


REAL 


1 REAL 


tangens- function 


21100 


AS IN 


REAL 


REAL 


inverse sine- 
function 


21105 


ACQS 


REAL 


REAL 


inverse 
cosine-function 
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ari_ 
opl_ 
code 


opl_ 
sym- 
bol 


type 

of 

result 


type 

of 

oper. 


explanation 


21110 1 LN 1 REAL | REAL | natural logarithm 


21111 


EXPN 


REAL 


REAL 


natural exponenta- 
tion 



7.4.1.2 Arithmetic operations with two operands 

Arithmetic operations with two operands are arranged in the following table. The operands should be on 
the stack. The operands are replaced and after the operation the result is on the top of the stack. In the 
column "types of operands" of the table below the rightmost specified operand is the top of stack (TOS, 
i.e. the last one pushed). 

Group of compliance: group A, level 

Syntax: 

ari„op2 ::= op2_symbol | ari_op2_code . 

op2_symbol = symbol for the arithmetic operator 

(see table) 
ar i_op2_code = code ( see table ) { integer ) 



21120 



ari„ 
op2_ 
code 


op2„ 
sym- 
bol 


type 
of 
result 


types 

of 

operands 


explanation 


21115 


ADDER 


BRADR 


BRADR BRADR 


addition of block 
relative addresses 
and address offset 



MULBR BRADR BRADR INT 



multiplication of 
block relative 
addresses and 
address offset 



21125 


ADDI 


INT 


INT 


INT 


addition of 
integers 


21130 


ADDR 


REAL 


REAL 


REAL 


addition of reals | 


21135 


ADDP 


POS 


POS 


POS 


addition of 
positions 


21140 


ADDJ 


JOINT 


JOINT 


JOINT 


addition of 
joints 
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21170 



21185 



ari_ 
op2_ 
code 


op2_ 
sym- 
bol 


type 
of 
result 


types 

of 

operands 


explanation 


21145 


ADDEP 


POSE 


POSE POS 


pose translation 
(addition of posi- 
tions , orientation 
unchanged) 


21150 


SUBI 


INT 


INT INT 


subtraction of 

integers 

(TOS-l minus TOS) 


21155 


SUBR 


REAL 


REAL REAL 


subtraction of 

reals 

(TOS-l minus TOS) 


21160 


SUBP 


POS 


POS POS 


subtraction of 
positions 
(TOS-l minus TOS) 


21165 


SUBJ 


JOINT 


JOINT JOINT 


subtraction of 

joints 

(TOS-l minus TOS) 



SUBEP POSE POSE POS 



pose translation 
(subtraction of 
position, orien- 
tation unchanged) 
(TOS-l minus TOS) 



21175 


MULI 


INT 


INT 


INT 


multiplication of 
integers 


21180 


MULR 


REAL 


REAL 


REAL 


multiplication of 
reals 



MULPI POS POS INT 



multiplication of 
each component of 
position by 
integer 



21190 



MULPR 



POS 



POS REAL 



multiplication of 
each component of 
position by real 



21195 I ROTP I POS I POS ORI 
21200 ROTO ORI ORI ORI 



position-rotation | 



orientation- 
rotation, i.e. the 
rotation defined 
by the second 
orientation will 
be applied to the 
first orientation 
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ari„ 


op2_ 


type 


types 


explanation 


op2_ 


sym- 


of 


of 




code 


bol 


result 


operands 




21^05 


TRANSP 


POS 


POSE POS 


posit ion-trans- 
foimation (rota- 
tion of position) 
according to ori- 
entation of pose 
and translation 



21210 ROTE POSE 



POSE ORI 



pose-rotation, 
i.e. the rotation 
defined by the 
second orientation 
will be applied to 
the orientation 
of the pose 



21215 



TRANSE 



POSE 



POSE POSE 



pose- trans for- 
mation 



21220 DIVI INT 



INT 



INT 



division of 

integers 

(divide TOS-1 by 

TOS) 



21225 



DIVR 



REAL 



REAL REAL 



division of reals 
(divide TOS-1 by 
TOS) 



21230 DIVPI POS 



POS 



INT 



division of each 
component of 
position by int. 
(divide TOS-1 by 
TOS) 



21235 



DIVPR 



POS 



POS 



REAL 



division of each 
component of 
position by real 
(divide TOS-1 by 
TOS) 



I 21240 I MOD I INT 
21245 RELE POSE 



INT INT I modulo function 



I 



POSE POSE 



pose-relation 
(inverse of TRANSE) 
calculates the 
translation and 
rotation to come 
from the second 
pose to the first 
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ari_ 
op2_ 
code 



op2_ 
sym- 
bol 



type 
of 
result 



types 

of 

operands 



explanation 



21250 



ATAN2 



REAL 



REAL REAL 



inverse 

tangens- function 
of a quotient 
(result is in the 
interval ( -pi , pi ] 
and is equal to 
the arc component 
of the polar coor- 
dinate of the 
cartesian value 
pair ( operand_2 , 
operand_l) . 
oper£uid_2 corres- 
pondends to X 
(TOS) and ope- 
rand_l corresponds 
to Y (TOS-1) ) 



21255 1 


EQB I 


BOOL 


BOOL 


BOOLJ 


equality of bool, | 


21260 


EQC 


BOOL 


CHAR 


CHAR 


equality of 
characters 


21265 


EQI 


BOOL 


INT 


INT 


equality of int. | 


21270 


EQR 


BOOL 


REAL 


REAL 


equality of reals | 


21275 


EQP 


BOOL 


POS 


POS 


equality of 
positions 


21280 


EQO 


BOOL 


ORI 


ORI 


equality of 
orientations 


21285 


EQE 


BOOL 


POSE 


POSE 


equality of poses | 


21290 


EQS 


BOOL 


STR 


STR 


equality of 
strings 


21295 


NEB 


BOOL 


BOOL 


BOOL 


inequality of 
booleeins 


21300 


NEC 


BOOL 


CHAR 


CHAR 


inequality of 
characters 


21305 


NEI 


BOOL 


INT 


INT 


inequality of 
integers 


21310 


NER 


1 BOOL 


1 REAL 


REAL 


inequality of reals 


21315 


NEP 


BOOL 


POS 


POS 


inequality of 
positions 
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21335 



ari_ 
op2_ 
code 


op2_ 

sym- 
bol 


type 
of 
result 


types 

of 

operands 


explanation 


21320 


NEO 


BOOL 


ORI ORI 


inequality of 
orientations 


21325 1 NEE | BOOL | POSE POSE | inequality of poses 


21330 


NES 


BOOL 


STR STR 


inequality of 
strings 



GTI 



BOOL 



INT INT 



comparison for 
greater than 
of integers 
(TOS-1 > TOS) 



21340 



GTR 



BOOL 



REAL REAL 



comparison for 
greater than 
of reals 
(TOS-1 > TOS) 



21345 



LTI 



BOOL 



INT INT 



comparison for 
less than 
of integers 
(TOS-1 < TOS) 



21350 



LTR 



BOOL 



REAL REAL 



comparison for 
less than 
of reals 
(TOS-1 < TOS) 



21355 



GEI 



BOOL 



INT INT 



comparison for 
greater than 
or equal to 
of integers 
(TOS-1 >= TOS) 



21360 



GER 



BOOL 



REAL REAL 



comparison for 
greater than 
or equal to 
of reals 
(TOS-1 >= TOS) 



21365 



LEI 



BOOL 



INT INT 



comparison for 
less than 
or equal to 
of integers 
{ TOS-1 <= TOS) 



21370 



LER 



BOOL 



REAL REAL 



comparison for 
less than 
or equal to 
of reals 
(TOS-1 <= TOS) 



41 



IS 15035:2001 
ISO/TR 10562 : 1995 



7.4.2 Boolean and bitwise operations 



7.4.2.1 Boolean and bitwise operations with one operand 



Boolean and bitwise operations with one operand are arranged in the following table. The operand should 
be on the top of the stack. The operand is replaced and after the operation the result is on the top of the 

stack. 

Group of compliance: group A, level ^ 

Syntax: 

b_opl ::= b_opl„syinbol | b_opl_code . 

b_opl_syinbol = symbol for the Boolean operator 

(see table) 
b_opl_code = code (see table) (integer) 



b„ 

opl— 
code 


b„ 
opl_ 
symbol 


type 
of 
result 


type 

of 

operand 


explanation 


21375 1 NOTE ( BOOL | BOOL | negation of boolean 


21380 


NOTI 


INT 


INT 


negation of integer 
bit by bit 



7.4.2.2 Boolean and bitwise operations with two operands 

Boolean and bitwise operations with two operands are airanged in the following table. The operands 
should be on the stack and the second operand is on the top of the stack. The operands are replaced and 
after the operation the result is on the top of the stack. In the colunm "types of operands" of the table 
below the rightmost specified operand is the top of stack (TOS, i.e. the last one pushed). 

Group of compliance; group A, level 

Syntax: 

b_op2 : : = b_op2_symbol | b_op2_code . 

b__op2_symbol = symbol for the Boolean operator 

(see table) 
b_op2_code = code (see table) (integer) 
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b_ 

op2_ 

code 


b_ 
op2_ 
symbol 


type 
of 
result 


types 

of 

operands 


explanation 


21385 


ANDB 


BOOL 


BOOL BOOL 


logical conjunc- 
tion of Booleans 


21390 


ANDI 


INT 


INT INT 


logical conjunc- 
tion of integers 
bit by bit 


21395 


ORB 


BOOL 


BOOL BOOL 


logical disjunc- 
tion of Boolecins 


21400 


ORINT 


INT 


INT INT 


logical disjunc- 
tion of integers 
bit by bit 


21405 


XORB 


BOOL 


BOOL BOOL 


logical exclusive 
or of Booleans 


21410 


XORI 


INT 


INT INT 


logical exclusive 
or of integers 
bit by bit 



7.4.3 Generation operations 



Generates a type from components. The generation operations are arranged in the following table. The 
operands should be on the stack and the last operand is on the top of the stack. The operands are replaced 
and after the operation the result is on the top of the stack. In the column "types of operands" of the table 
below the rightmost specified operand is the top of stack (TOS, i.e. the last one pushed). 

Group of compliance: group A, level 

Syntax: 

gen_op : : = gen_op_syinbol | gen_op_code . 

gen_op„syinbol = symbol for the Boolean operator 

(see table) 
gen_op_code = code (see table) (integer) 
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gen_ 

op_. 

code 


gen_ 
op_ 
symbol 


type 
of 
result 


types 
of 
components 


explanation 


21415 


GENP 


POS 


REAL, REAL, 
REAL 


generation of a POS 
from three reals in 
sequence of X,Y, and 
Z on TOS 


21420 


GENO 


ORI 


INT, REAL, 
REAL, REAL, 
REAL 


generation of an ORI 
from one integer and 
four reals in the 
sequence of ori_id, 
a,b,c, and d on TOS 


21425 


GENE 


POSE 


POS, ORI 


generation of a pose 
from a position and 
an orientation (in 
this sequence) 


21430 


GENERO 


POSE 


REAL, REAL, 
REAL, ORI 


generation of a pose 
from three reals and 
an orientation in 
the sequence of X,Y, 
Z, and ORI on TOS 



21435 



GENEPR 



POSE 



POS, INT, 
REAL, REAL, 
REAL, REAL 



generation of a pose 
from a position, one 
integer and four 
reals in the se- 
quence of pos,ori_- 
id, a, b, c, and d 
on TOS 



21440 



GENERR 



POSE 



REAL, REAL, 
REAL, INT, 
REAL, REAL, 
REAL, REAL 



generation of a pose 
from three reals, one 
integer and four 
reals in the se- 
quence of X, Y, Z, 
ori_id, a, b, c, 
and d on TOS 



21441 



GENT 



ROBTRT 



POSE, INT, 

INT 

ADJOINT 



generation of a rob- 
target from a pose, 
an integer (status) , 
integers (nturns) 
and an add_joint in 
the sequenz pose, 
status, nturns and 
add_joint on TOS 



21442 



GENM 



M 



JOINT 



REAL, 



generation of a 
M_JOINT from reals 
in sequenz of axis 
1,2,... on TOS 
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gen_ 


gen_ 


type 


types 


explcination 


op_ 


op_ 


of 


of 




code 


symbol 


result 


components 




21443 


GEND 


A_ 
JOINT 


REAL, . . . 


generation of a 
A_JOINT from reals 
in sequenz of add_ 
axis 1,2,... on TOS 


21444 


GENJ 


JOINT 


M_ JOINT, 
A_JOINT 


generation of JOINT 
from a M_JOINT and a 
A_ JOINT in this 
sequenz on TOS 


21445 


GENJRD 


JOINT 


REAL 

A_JOINT 


generation of a 
JOINT from reals 
(axis 1,2, ... ) and a 
A_JOINT in this 
sequenz on TOS 


21446 


GENJMR 


JOINT 


M_ JOINT, 
REAL, . , . 


generation of a 
JOINT from a M_JOINT 
and reals ( add_axis 
1,2, .. ) in this 
sequenz on TOS 


21447 


GENJRR 


JOINT 


REAL, . . . , 
REAL, . . . 


generation of a 
JOINT from reals 
(axis 1,2, ... ) and 
reals ( add_axis 
1,2, . .) in this 
sequenz on TOS 



7.4.4 Operations on strings 



Operations on strings are arranged in the following table. The operands should be on the stack. The 
sequence of operands follows the mentioned order of the colunui "types of components". After the 
operation they are replaced and the resuh is on the top of the stack. 

Group of compliance: group A, level 

Syntax: 

str_op ::= str„op_syinbol | str_op_code . 



s t r_op_syinbo 1 = 
str_op_code = 



symbol for the string operator (see table) 
code (see table) (integer) 
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str_ 


str„ 


type 


types 


explanation 


op_ 


op„ 


of 


of com- 




code 


symbol 


result 


ponents 




21450 


APPENDC 


STR 


STR, CHAR 


the character is 
appended to the end 
of the string 


21455 


CONCATS 


STR 


STR, STR 


the characters of 
the second string 
are appended to the 
first one 


21460 


EXTRCTS 


STR 


STR, INT; 
INT 


extract a part of a 
string, the first 
integer is the 
starting, the second 
integer is the final 
index, the first 
index has to be less 
than or equal to the 
second one 



21465 



GETCHR 



CHAR 



STR, INT 



get one character 
out of the string, 
indexed by the 
integer 



21470 



SETCHR 



STR 



STR, CHAR, 
INT 



set one character 
into the string, 
indexed by the 
integer 



2147 5 LENGTHS INT 



STR 



get the length of 
the string (number 
of characters) 



7.4.5 Stack operations 



7.4.5.1 Push and pop operations with constant size 



The push and pop operations with constant size are anranged in the following tables. The size is 
implementation dependent. 

Type casting should only be done by generation operations and not by push and pop statements. 

For example, it is not allowed to push a real value on the top of the stack and then to pop this value to an 
object of type integer. 
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The operand of the POP-instructions should not be a constant. 

Group of compliance: group A, level 

Syntax: 

pap_op_c : : = ( pap_op_synibol | pap_op_code ) [ ' , ' operand ] 

pap_op_syinbo 1 = 



pap_op_code 
operand 



pap„op_ 
code 

21480 



pap_op_ 

symbol 

PUSHB 



#^jSnibbl iftar-'tffti^ Efct^h and pop operator 

^§m -m«^m^%ctmt ^operands • 

— _- — ^-^^^■^^^oM^^^J^-^'^^'j.^- : 

type of [ ®<^l.dhatibn 
operand ' ■ f ' ' '^^^ '^ ^' 



BOOL 



th^ boolean value 
f^ pushed on TOS 



21485 


PUSHC 


CHAR 


the character value 
is pushed on TOS 


21490 


PUSHI 


INT 


the integer value 
is pushed on TOS 


21495 


PUSHR 


REAL 


the real value 
is pushed on TOS 


21500 


PUSHP 


POS 


the position value 
is pushed on TOS 


21505 


PUSHO 


ORI 


the orientation value 
is pushed on TOS 


21510 


PUSHE 


POSE 


the POSE value 
is pushed on TOS 


21515 


PUSHT 


ROBTRT 


the robot target value 
is pushed on TOS 


21520 


PUSHJ 


JOINT 


the joint value 
is pushed on TOS 


21525 


PUSHS 


STR 


the string value 
is pushed on TOS 


21530 


PUSHA 


BRADR 


the operand value 

(i.e. the address of some 
object) is pushed on TOS 


21531 


PUSHER 


BRADR 


a blockrelative address 
is pushed on TOS 



47 



IS 15035 : 2001 
ISO/TR 10562 : 1995 



pap_op_ 
code 


pap_op_ 
symbol 


type of 
operand 


explanation 


21532 


PUSHAA 


absolute 
address 


an absolute address 
is pushed on TOS 


21535 


POPB 


BOOL 


a boolean is popped to 
the abs. address or symbol 


21540 


POPC 


CHAR 


a character is popped to 
the abs. address or symbol 


21545 


POPI 


INT 


an integer is popped to 
the abs. address or symbol 


21550 


POPR 


REAL 


a real is popped to 

the abs. address or symbol 


21555 


POPP 


POS 


a position is popped to 
the abs , address or symbol 


21560 


POPO 


ORI 


an orientation is popped to 
the abs. address or symbol 


21565 


POPE 


POSE 


a POSE is popped to 

the abs . address or symbol 


21570 


POPT 


ROBTRT 


a robtarget is popped to 
the abs. address or symbol 


21575 


POPJ 


JOINT 


a joint is popped to 

the abs. address or symbol 


21580 


POPS 


STR 


a string is popped to 

the abs. address or symbol 


21585 


POPA 


BRADR 


an address is popped to 
the blockrelative address 
or symbol 


21590 


DUPB 


BOOL 


duplicate the boolean 
value of TOS into TOS and 
TOS-1 


21595 


DUPC 


CHAR 


duplicate the character 
value of TOS into TOS and 
TOS-1 


21600. 


DUPI 


INT 


duplicate the integer 
value of TOS into TOS and 
TOS-1 


21605 


DUPR 


REAL 


duplicate the real 

value of TOS into TOS and 

TOS-1 
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pap_op_ 
code 


pap_op_ 
symbol 


type of 
operand 


explanation 


21610 


DUPP 


POS 


duplicate the position 
value of TOS into TOS and 
TOS-1 


21615 


DUPO 


ORI 


duplicate the orientation 
value of TOS into TOS and 
TOS-1 


21620 


DUPE 


POSE 


duplicate the pose 

value of TOS into TOS and 

TOS-1 


21625 


DUPT 


ROBTRT 


duplicate the robtarget 
value of TOS into TOS and 
TOS-1 


21630 


DUPJ 


JOINT 


duplicate the joint 
value of TOS into TOS and 
TOS-1 


21635 


DUPS 


STR 


duplicate the string 
value of TOS into TOS and 
TOS-1 


21640 


DUPA 


absolute 
address 


duplicate the absolut ad- 
dress of TOS into TOS and 
TOS-1 


21645 


SWAPB 


BOOL 


the boolean values of 
TOS and TOS-1 are swapped 


21650 


SWAPC 


CHAR 


the character values of 
TOS and TOS-1 are swapped 


21655 


SWAPI 


INT 


the integer values of 
TOS and TOS-1 are swapped 


21660 


SWAPR 


REAL 


the real values of 

TOS and TOS-1 are swapped 


21665 


SWAPP 


POS 


the position values of 
TOS and TOS-1 are swapped 


21670 


SWAPO 


ORI 


the orientation values of 
TOS and TOS-1 are swapped 


21675 


SWAPE 


POSE 


the POSE values of 

TOS and TOS-1 are swapped 
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pap_op_ pap_op_ 
code I symbol 


type of 
operand 


explanation 


21680 


SWAPT 


ROBTRT 


the robot target values of 
TOS and TOS-1 are swapped 


21685 


SWAPJ 


JOINT 


the joint values of 

TOS and TOS-1 are swapped 


21690 


SWAPS 


STR 


the string values of 

TOS and TOS-1 are swapped 


21695 


SWAPA 


absolute 


the absolute addresses on 
TOS and TOS-1 are swapped 



Note 



TOS means on the top of the stack. 



7*4.5.2 Push and pop operations with variable size 

The push and pop operations with variable size are an*anged in the following table. 

Group of compliance: group A, level 
Syntax: 

pap_opv : : = 

( pap_opv_syinbol | pap_opv_code ) 
' , ' size [ ' , ' operand ] . 

pap_opv_syinbol = symbol for push and pop operator 

(see table) 
pap_opv__code = code (see table) (integer) 

size = size of the operand in byte (integer) 
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pap_ 
opv_ 
code 


Pap_ 

opv_ 

symbol 


size 


type of 
operand 


explanation 


21700 


PUSHV 


actual 
size 


constant 
or abs. 
address 
or symbol 


a value with the 

given size 

is pushed on TOS 


21705 


PUSH 


actual 
size 


- 


*size* bytes on the 
stack are allocated 


21710 


POPV 


actual 
size 


absolut 
address 
or symbol 


a value with the 
given size is popped 
to the abs. address 
or symbol 


21715 


POP 


actual 
size 


- 


'size* bytes on the 
stack are released 


21720 


LOAD 


actual 
size 




the abs. address or 
symbol at the 
TOS is replaced by 
the value 


21725 


STORE 


actual 
size 




a value (TOS-1) and 
an absolut address 
or symbol (TOS) are 
on the stack. 
The value is stored 
at the abs. address 
or symbol. Value and 
address or symbol 
are popped 



The push and pop operations with sizes using a data type specification instead of an explicit size 
specification are arranged in the following table: 



Group of compliance: group A, level 

Syntax: 

pap ,opvd : := ( pap_opvd_symbol | pap_opvd_code ) ' , ' type 
[ ' , ' operand ] . 



pap_opvd_symbo 1 

pap_opvd_c ode 

type 

operand 



symbol for the push and pop operator 

(see table) 

code (see table) (integer) 

data type of the operand (integer) 

see chapter * access to operands' 
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pap_ 

opvd_ 

code 


pap_ 
opvd_ 
symbol 


type 


type of 
operand 


explanation 


21726 


PUSHVD 


type 


blockrel, 
address 
or symbol 


a value of the size 
according to the 
specified type is 
pushed on TOS 


21727 


POPVD 


type 


blockrel . 
address 
or symbol 


a value of the size 
according to the 
specified type is 
popped to the operand 


21728 


LOADVD 


type 




the blockrel. addr. 
or symbol at the TOS 
is replaced by the 
value of the speci- 
fied type 



21729 



STOREVD 



type 
size 



a value (TOS-1) and 
a block relative 
address (TOS) are on 
the stack. 
The value is stored 
at this address » 
Value and address 
are popped 



7.4.5.3 Push and pop operations with variable number of elements of fixed data type 



The push and pop operations with variable number of elements of fixed data type can be used for pushing 
and popping whole arrays. 

Group of compliance: group A, level 

Syntax: 

pap__opvf t : : = 

( pap_opvft_symbol | pap_opvf t_code ) 
' , ' el_nr ' , ' el_type ' , ' operand . 

pap_opv f t _symbo 1 = 



pap__opvf't__code 
el_nr 
el„type 
operand 



symbol for push and pop operator 

(see table) 

code (see table) (integer) 

number of elements (integer) 

element data type (integer) 

see chapter ' access to operands ' 
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pap_ 

opvft„ 

code 


pap_ 
opvft_ 
symbol 


explanation 


21730 


PUSHED 


a field is pushed 
on TOS 


21731 


POPFD 


a field is popped 

to the abs . address or symbol 



7.4.5.4 Operations for address calculation 

To address an array element the starting address of the array must be increased by 
"nr_of_elements_before_the_wanted_one" multiplied with "size_of_one_array_element". 

The "size_of_one_array_element" can be pushed onto the stack with the PUSHSZ operation (see below). 

The "nr_of_elements„before_the_wanted_one" normally is an expression of the form 

"index_value" minus "lower_bound_of_array". 

This number of elements is normally computed on the stack with integer arithmetic. 

These two values (the size of one element and the number of elements) must then be multiplied with the 
MULBR operation. The result of that multiplication can then be added to the starting address of the array 
with the ADDBR operation. 

Group of compliance: group A, level 
Syntax: 

pushsz ::= ( pushsz_symbol | pushsz_code ) *,* type. 



pushs z„symbo 1 = 
pushsz_code = 
type 



' PUSHSZ • . 

21735 (integer) . 

element data type (integer) . 



The size occupied by one element of that type is pushed onto the stack. 

Remark: 

If all records of the same data type are aligned uniformly on the real target memory, then the loader can 
transform the block relative indices and offsets to addresses and address offsets in absolute memory 
space. If there are gaps between two adjacent elements caused by alignment, the size value that is pushec 
must include the size of that gap. 

To address fields of a record the starting address of the record must be increased by the distance to the 
wanted field. This distance can be added to the starting address with the ADD_DIST operation: 

Group of compliance: group A, level 
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Syntax: 



add_dist : :^ ( add_dist_syTnbol | add„dist_code ) 
' , ' operandi * , ' operand2 , 

add_dist_syTnbol = •ADD_DIST* . 

add_dist_code = 21740 (integer) 

operandi = blockrelative address or syi|Ox)l of the 

record containing the wanted field. 
operand2 = blockrelative address or symbol of the 

wanted field. 

The distance from (the beginning of the record specified by) ppfppctl tp (^||jf^i^ f|5^f| spM|f fd.b^) 
operand2 is added to the block relative address on TOS. Thiis address was previously pusmd onto the 
stack with a PUSHER operation. 



7.5 Technical specifications 

Some robot controller system variables are used to specify the technical specifications of the robot or the 
current status of the robot. These system variables can define the features of the robot movement, such as 
the acceleration and the velocity of the robot tool center point (called TCP in the text) or the accuracy on 
pose, that is the distance between command and attained pose. 

According to the definition of general robotic terms in ISO/TR 8373, the two kinds of robot movements 
can be described as follows: 

- pose to pose movement: it is specified to move the robot as rapidly as possible between any two 

poses in the working space. The movement is characterized by an initial pose (often called "initial 
point") and the next pose which is the endpose (often called "endpoint"). 

- continuous path: it is specified to move the robot along a continuously controlled path. The path is 

characterized by an initial pose, one or more intermediate poses (often called "viapoints") and an 
endpose. 

The system variables are initialized by default and can be modified at the start of the programme. The 
values by default are given by the robot manufacturer. Thus, when a variable is modified, its modification 
will run until it is superceded by another change. 

The following statements permit access to the global variables of the system by using in most cases the 
numerical code or the mnemonic R_xxx (Read system variable xxx) and permit modification of these 
variables by using the mnemonic W_xxx (Write variable xxx). The syntax of these statements is: 

- 'R_xxx' to obtain the value of the xxx system variable located in the robot controller and to push this 

value on the top of stack 

- 'W_xxx' to set up the value of a xxx variable located on the top of stack in the specific location of the 

corresponding system variable into the robot controller. 

For instance, the 'R_ACCEL' statement reads the value of the progranmied acceleration of TCP in the 
robot controller and pushes this value on top of stack. The W_ACCEL' statement performs the inverse 
operation by popping the value of the variable from the top of stack and writing this value into the 
acceleration system variable of the robot controller. This value becomes the new programmed value of the 
TCP acceleration. 
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The variables in the statements are transmitted by using the LIFO stack (as defined in paragraph "Access 
to operand" in chapter "Basic concepts"). 



Syntax: 
specification : := 



r_accel 
mvtmout 
identir 



w_accel 
r_resdp 
selectir 



r__vel I w_vel | r_movtim | w_movtim 
w^resdp | r_resip | w_resip | 
I curpos . 



The symbolic named ERRSPE variable is used to characterize the result of the statements execution set 
by the pontroller. The structured ERRSPE variable contains two elements, the statement operator code 
followed by the error value: 



RECORD 

Statement: 
error_code : 

END; 



STRING 
INTEGER 



The value by default is zero (no error). Negative values are used for standardized codes of errors, and 
positive values ('i' errors) are robot-dependent and supplied by the robot manufacturer. 

For the following statements, standard negative values of error code are given. 



7.5.1 Reading the movement acceleration (R_ACCEL) 



Reading the programmed movement acceleration value of the current robot TCP. The value of 
acceleration is pushed on top of stack from the robot controller acceleration system variable. 

Group of compliance: group B, kernel 

Syntax: 



r_accel : : 

cd__r_accel : ; 

r_accel_code 
accel_type 



accel kind 



= cd_r_accel 

: = ' R ACCEL ' I 



' , ' accel_type 
r_accel_code , 



accel_kind 



Stack: 



=> 



I_l : integer 
0__1 : real 



2000 (integer) 

acceleration type code (character) 

J = joint actuator acceleration 

T = TCP acceleration in robot geometrical 

referential 
kind of acceleration (integer) 

1 = in % of max. acceleration given by 

manufacturer 

2 = in m/s2 

3 = in rad/s2 
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Semantical explanation: 

l_l: number of axis considered 

= all axes 

i = axis number i 
0_1: value of acceleration 

Error code: 

-1 = no compatibility between accel_kind and 
accel_type. 

For instance if accel_type is set to 'J' and 
accel_kind to '2* for a revolute robot, an error 
code is returned. 

The translational and/or rotational acceleration of the TCP along the next movement (pose-to-pose 
movement or continuous path) in the robot geometrical referential (acceUype is T) is given by the 
accel_kind parameter which specifies: 

if 1: % of both translational and rotational acceleration of the TCP 
if 2: value of the translational acceleration of the TCP 
if 3: value of the rotational acceleration of the TCP 



7.5.2 Writing the movement acceleration (W„ACCEL) 

Writing the movement acceleration value of the current robot TCP. The value of acceleration is popped 
from the top of stack and written into the robot controller acceleration system variable. 

Group of compliance: group B, kernel 

Syntax: 

w„accel : : = cd_w„accel ' , ' accel„type ' , ' accel_kind . 
cd_w_accel : := 'W_ACCEL' | w_accel_code . 

w_accel_code = 2050 (integer) 

accel„type = acceleration type code (character) 

J = joint actuator acceleration 
T = TCP acceleration in robot geometrical 
referential 

accel_kind = kind of acceleration (integer) 

1 = in % of max. acceleration given by 

manufacturer 

2 = in m/s2 

3 = in rad/s2 

Stack: 

I„2 : real , I„l : integer 
=> (no result) 
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Semantical explanation: 

I_2 : value of the acceleration 
I_l: number of axis considered 

= all axes 

i = axis number i 

Error code: 

-1 = no compatibility between accel_kind and 

accel_type. 

For instance if accel_type is set to 'J' and 

accel_kind to '2' for a revolute robot, an error 

code is returned. 
-2 = illegal value of acceleration (out of range) 

The translational and/or rotational acceleration of the TCP along the next movement (pose-to-pose 
movement or continuous path) in the robot geometrical referential (accel_type is T') is given by the 
accel_kind parameter which specifies: 

if 1: % of both translational and rotational acceleration of the TCP 
if 2: value of the translational acceleration of the TCP 
if 3: value of the rotational acceleration of the TCP 



7.5.3 Reading the movement velocity (R_VEL) 

Reading the programmed movement velocity value of the current robot TCP. The value of velocity is 
pushed on top of stack from the robot controller velocity system variable. 

Group of compliance: group B, kernel 
Syntax: 

r_vel : : := cd_r_vel ' , ' vel^type ' , ' vel_kind . 
cd_r_vel ::= ' R_VEL ' | r„vel_code . 

r_vel_code = 2100 (integer) 

vel_type - velocity type code (character) 

J = joint actuator velocity 
T = TCP velocity in robot geometrical 
referential 

vel_kind = kind of velocity (integer) 

1 = in % of max. velocity given by 

manufacturer 

2 = in m/s 

3 = in rad/s 

Stack: 

I_l : integer 
=> 1: real 
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Semantical explanation: 

I_l: number of axis considered 

= all axes 

i = axis number i 
0_1 : velocity 

Error code: 

-1 = no compatibility between vel_kind and vel_type. 
For instance if vel_type is set to 'J' and 
vel_kind to '2' for a revolute robot, an error 
code is returned. 

The translational and/or rotational velocity of the TCP along the next movement (pose-to-pose movement 
or continuous path) in the robot geometrical referential (veLtype is T') is given by the veLkind 
parameter which specifies: 

if 1: % of both translational and rotational velocity of the TCP 
if 2: value of the translational velocity of the TCP 
if 3: value of the rotational velocity of the TCP 



7.5.4 Writing the movement velocity (W„VEL) 

Writing the movement velocity value of the current robot TCP. The value of velocity is popped from the 
top of stack and written into the robot controller velocity system variable. 

Group of compliance: group B, kernel 

Syntax: 

W_VEL : : = cd_w_vel ' , * vel_type ' , ' vel_kind . 
cd_w_vel : : = ' W_VEL * | w„vel_code . 

w_vel_code = 2150 (integer) 

vel_type = velocity type code (character) 

J = joint actuator velocity 
T = TCP velocity in robot geometrical 
referential 

vel_kind = kind of velocity (integer) 

1 = in % of max. velocity given by 

manufacturer 

2 = in m/s 

3 = in rad/s 

Stack: 

I_2 : real , I_l : integer 
=> (no result) 

Semantical explanation: 

I_2 : velocity 

I_l: number of axis considered 

= all axes 

i = axis number i 
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Error code: 

-1 = no compatibility between vel_kind and vel_type. 
For instance if vel_type is set to 'J' and 
vel_kind to '2' for a revolute robot, an error 
code is returned. 

-2 = illegal value of velocity (out of range) 

The translational and/or rotational velocity of the TCP along the next movement (pose-to-pose movement 
or continuous path) in the robot geometrical referential (veLtype is T') is given by the vel_kind 
parameter which specifies: 



if 1 : % of both translational and rotational velocity of the TCP 
if 2: value of the translational velocity of the TCP 
if 3: value of the rotational velocity of the TCP 



7.5.5 Access to the duration of a movement (R_MOVTIM) 



Reading the execution time of a given movement. This information is present in the robot controller in 
order to inform the programme that the movement is executed or in progress. The movement completes 
when the robot overshoot is less than the robot accuracy on the destination pose. An xMOVE statement 
(see paragraph 7.6 "Movement control") resets at the timer value until the end of the movement 
execution. Then, the value of execution time is pushed on top of stack. During the movement, the timer 
value is (movement in progress). At the end of the movement, the timer value is the execution time. 

Group of compliance: group B, kernel 

Syntax: 

r_movtiin ::= cd_r_movtim . 

cd_r__movtim ::= •R_MOVTIM' | r_movtim_code . 

r_inovt im_code = 2 2 ( integer ) 

Stack: 

=> 0_1: real 

Semantical explanation: 

0_1: execution time: 

= movement in progress 

n = execution time in s given at the end of the last 
movement 

Error code: 

-1 = no movement in progress 
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7.S.6 Setting up the duration of a movement ( W_MOVTIM) 

Setting up the duration of a given movement. This statement will change the velocity of the robot if 
necessary in order to execute the next xMOVE statement in the specified execution time. The value of the 
duration is popped from the top of stack. 

Group of compliance: group B, kernel 

Syntax: 

w_movtim ::= cd_w__movtim . 

cd_w_movtim ::= •W_MOVTIM' | w_movtim_code . 

w_movt im_code = 2 2 5 { integer ) 

Stack: 

I„l: real 
=> (no result) 

Semantical explanation: 

I 1: movement execution time in s 



7.5.7 Setting up a time-out of a movement (MVTMOUT) 

Setting up a time-out of a given movement. The value of the time-out is popped from the top of stack. If 
the movement is in progress at the end of time-out, an error code is set to -1 in the corresponding xMOVE 
statement. If no time-out is specified, a max. value is given by default. 

Group of compliance: group B, extensions 

Syntax: 

mvtmout : := cd_mvtmout . 

cd_mvtmout : : = ' MVTMOUT ' | mvtmout„code . 

mvtmout_code = 2 3 { integer ) 

Stack: 

I_l: real 
=> (no result) 

Semantical explanation: 

I 1: movement execution time-out in s 
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7.5.8 Reading the robot accuracy on destination pose (RD_ACCDP) 

The robot accuracy on destination pose determines how close to the destination pose the TCP must be 
before the movement is considered complete (pose overshoot). This area of inaccuracy is called 'pseudo- 
sphete' because each axis in geometrical referential or each joint has its own measurement unit. The 
current value of accuracy is pushed on top of stack. 



Groiip of conpliance: group B, extensions 

Syntax: 

rd^accdp j: := cd^rd^accdp^a^i^*' €wcfedp_type ' , ' accdp.kind . 
cd_rd_accdp I: := *BDJMlCIiB;f ^4^>^djac€dp_code . 

rd„accdp_code = 2400 itdMifegwr^) 

accdp_type = accuracy type code (character) 

J 3^ GH>ix^ auEtuatcr value 
T = TCP accuracy in robot geometrical 
referential 

accdp_kind = kind of accuracy (integer) 

1 = in % of max. accuracy given by 

manufacturer 

2 = radius of the smoothing pseudo-sphere 

in mm 

3 = radius of the pseudo-sphere in encoder 

increments 

Stack: 

I__l : integer 
=> 0_1 : integer 

Semantical explanation: 

I__l : nuiT±>er of axis considered 

= all axes 

i = axis number i 
0_1 : value of the accuracy 

If the robot controller cannot accept real values of the radius of the pseudo-sphere or percentages of max. 
accuracy, the nearest discrete value in concordance with the controller capability will be given. In most 
cases the industrial robot controllers accept discrete values or predefined constants such as 'fine', 'medium' 
or 'large'. 



7.5.9 Writing the robot accuracy on destination pose (W_ACCDP) 

The robot accuracy on destination pose determines how close to the destination pose the TCP must be 
before the movement is considered complete (pose overshoot). This area of inaccuracy is called 'pseudo- 
sphere' because each axis in geometrical referential or each joint has its own measurement unit. The 
specified value of accuracy is popped from the top of stack into the robot controller system variable. 
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Group of compliance; group B, extensions 

Syntax: 

w__accdp : : = cd_w_accdp ' , ' accdp_type ' , ' accdp_kind . 
cd_w_accdp : : = ' W_ACCDP ' | w_accdp_code . 

w__accdp_code = 2450 (integer) 

accdp_type - accuracy type code (character) 

J = joint actuator value 
T = TCP accuracy in robot geometrical 
referential 

accdp_kind = kind of accuracy (integer) 

1 = in % of max. accuracy given by 

manufacturer 

2 = radius of the smoothing pseudo-sphere 

in mm 

3 = radius of the pseudo-sphere in encoder 

increments 

Stack: 

I_2 : integer, I_l : integer 
-> (no result) 

Semantical explanation: 

I_2 : value of the accuracy 
I_l : number of axis considered 

= all axes 

i = axis number i 

If the robot controller cannot accept real values of the radius of the pseudo-sphere or percentages of max. 
accuracy, the nearest discrete value in concordance with the controller capability will be given. In most 
cases the industrial robot controllers accept discrete values or predefined constants such as 'fine', 'medium' 
or 'large'. 



7.5.10 Reading the robot accuracy on intermediate pose (RD_ACCIP) 

The robot accuracy on intermediate pose determines how close to the intermediate pose the TCP must be 
through a continuous controlled path. This area of inaccuracy is called 'pseudo-sphere' because each axis 
in geometrical referential or each joint has its own measurement unit. The current value of accuracy is 
pushed on top of stack. 

Group of compliance: group B, extensions 
Syntax: 

rd_accip : := cd_rd_accip ' , ' accip_type ' , * accip„kind . 
cd_rd__accip ::= 'RD_ACCIP' | rd_accip_code . 

rd_accip_code - 2 5 ( integer ) 

accip_type = accuracy type code (character) 

J = joint actuator value 
T = TCP accuracy in robot geometrical 
referential 
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accip_kind 



kind of accuracy (integer) 

1 = in % of max. accuracy given by 

manufacturer 

2 - radius of the smoothing pseudo- sphere 

in mm 

3 = radius of the pseudo-sphere in encoder 

increments 



Stack:! 



=> 



1: 



integer 
integer 



Semantical explanation: 

I_l : number of axis considered 

- all axes 

i = axis number i 
0_1: value of the accuracy 

If the robot controller cannot accept real values of the radius of the pseudo-sphere or percentages of max. 
accuracy, the nearest discrete value in concordance with the controller capability will be given. In most 
cases the industrial robot controllers accept discrete values or predefined constants such as 'fine', 'medium' 
or 'large'. 



7.5.11 Writing the robot accuracy on intermediate pose (W_ACCIP) 



The robot accuracy on intermediate pose determines how close to the intermediate pose the TCP must be 
through a continuous controlled path. This area of inaccuracy is called 'pseudo-sphere' because each axis 
in geometrical referential or each joint has its own measurement unit. The specified value of accuracy is 
popped from the top of stack into the robot controller system variable. 

Group of compliance: group B, extensions 

Syntax: 



W_accip : ; 
cd_w_accip : : 

w_accip_code 
accip_type 



accip_kind 



cd_w_accip ' , ' accip_type ' , ' accip_kind , 
' W_ACCIP • I w„accip_code . 

2550 (integer) 

accuracy type code (character) 
J = joint actuator value 
T - TCP accuracy in robot geometrical 
referential 
= kind of accuracy (integer) 

1 = in % of max. accuracy given by 

manufacturer 

2 = radius of the smoothing pseudo-sphere 

in mm 

3 = radius of the pseudo-sphere in encoder 

increments 



Stack: 



=> 



I_2 : integer , I_l : integer 
(no result) 
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Semantical explanation: 

I_l: nu^iber of the curent industrial robot 

Error code: 

-1 = unknown nurtdoer of robot 



7.5.14 Pose access (CURPOS) 

Reading the current pose of the robot TCP. The pose is pushed on top of stack from the robot controller 
current pose data. 

Group of compliance: group B, kernel 

Syntax: 

curpos : := cd_curpos ' , ' pose_type . 
cd_curpos ::= 'CURPOS' | curpos_code . 



curpos_code 
pose__type 



2900 (integer) 
pose type code (character) 
J = Joint actuator values 
T = TCP pose in robot geometrical 
referential (robtarget) 



Stack: 

= > 1: 



[joint I robtarget) 



Semantical explanation: 

0_1: current value of the pose of the robot 



7.6 Movement control 



The movement statements improve displacement of the robot tool center point between two poses defined 
by Joint type for displacements in axes coordinates and by Robtarget type for geometrical displacements 
in the robot geometrical referential. In this way, a synchronized movement of the robot and one or more 
auxiliary axes may be executed by using the global variable Add_Axis with the value 1 for Robtarget type 
definition (see clause 6 "Data types"). 

Syntax: 



Imove I cmove | pmove | movtrj | 
gohome | movbeg | movend | movstp 



movecontrol 
jmove 
calib 
movcont | movcancel 

A path consists of a set of given pose-to-pose movements into a block structure. Each of the given 
movements is executed by a movement statement. The initial pose is always the previous pose of the 
robot. 
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A trajectory may be teached by using teach pendant. The execution of such a trajectory can be performed 
by MOVTRJ statement. In this case, all the movements and associated parameters are taken into account 
directly by the robot controller. 

If no values are given to the system variables, a value by default is implicit. The accuracy of the robot on 
the intermediate poses is defined by the smoothing criterion description statements (see 7.5.9 and 7.5.1 1). 

The 'wait' parameter permits or not the execution of subsequent statements concurrent with execution of a 
movement. If 'wait' is set to 'W, the next statement will be executed when the movement completes or is 
cancelled. 

In case of elementary xMOVE statements in a path block, the *wait* parameter is not taken into account by 
the robot controller. The value of this parameter in the MOVBEG statement is valid all along the path 
until the next MOVEND statement. 

The destination poses (and the intermediate pose for CMOVE statements) on the top of stack are written 
by the xMOVE statements in the robot controller. Before executing a xMOVE statement, these poses 
must be pushed on top of stack. The description of these variables and the order in the LIFO stack is 
given for each statement. 

The symbolic named ERRMOV variable is used to characterize the result of the statements execution set 
by the controller. The structured ERRMOV variable contains two elements, the statement operator code 

followed by the error value: 

RECORD 

statement : STRING 

error__code : INTEGER 
END 

The value by default is zero (no error). Negative values are reserved for standardized codes of errors and 
positive values ('i' errors) are robot-dependent and given by the robot manufacturer. 

For the following statements, standard negative values of error code are given. 



7.6.1 Movement specified by joint interpolation (JMOVE) 

Control of a given robot movement to the next pose with joint interpolation. 

Group of compliance: group B, kernel 
Syntax: 

jmove : := cd_jmove ' , ' abs_rel ' , ' pose_type ' , ' wait 
cd_jmove ::= 'JMOVE' | jmove_code . 

jinove_code = 5010 (integer) 

abs_rel = type of displacement (integer) 

1 = absolute 

2 = relative 

pose_type = pose type code (character) 

J = joint actuator values 
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T = TCP pose in robot geometrical 
referential 
wait = specification that the application 

programme continues or not after JMOVE 

instrxfction without waiting for the end of 

the movement : 

W = wait for end of movement 

N = no wait for end of movement 

Stack: 

I„l: (joint if pose_type= ' J* | robtarget if 
pose_type=*T* ) 
=> , (no result) 

I 
Semantical explanation: 

I_l: value of the destination pose 

Error code: 

-1 = time-out before the end of the movement execution 



7.6.2 Linear interpolated movement (LMOVE) 

Control of a given robot movement with linear interpolation of the robot TCP to the next pose in the robot 
geometrical referential. 

Group of compliance: group B, kernel 
Syntax; 

Imove : := cd_lmove ' , ' abs„rel ' , • pose_type ' , • wait . 

cd_lmove : : = ' LMOVE ' | lmove„code . 

lmove_code = 5030 (integer) 

abs_rel = type of displacement (integer) 

1 = absolute 

2 = relative 

pose_type = pose type code (character) 

J = joint actuator values 

T = TCP pose in robot geometrical 
referential 
wait = specification that the application 

programme continues or not after LMOVE 

instruction without waiting for the end of 

the movement: 

W = wait for end of movement 

N = no wait for end of movement 

Stack: 

I_l: (joint if pose„type= * J' | robtarget if 
pose_type=*T' ) 
=> (no result) 
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Semantical explanation: 

I_l: value of the destination pose 

Error code: 

-1 = time-out before the end of the movement execution 



7.6.3 Circular interpolated movement (CMOVE) 

Control of a given robot movement with circular interpolation of the robot TCP to the next pose in the 
robot geometrical referential. An intermediate pose must be given in order to define a circle by mean of 
three poses. Both intermediate and destination poses must have the same data type. 

Group of compliance: group B, extensions 

Syntax: 

amove : := cd_cmove ' , ' abs_rel ' , * pose_type ' , ' wait . 
cd_cmove : : - CMOVE ' | cmove_code . 

cmove_code = 5 5 ( integer ) 

abs_rel - type of displacement (integer) 

1 = absolute 

2 = relative 

pose_type = pose type code (character) 

J = joint actuator values 

T = TCP pose in robot geometrical 
referential 
wait = specification that the application 

programme continues or not after CMOVE 

instruction without waiting for the end of 

the movement : 

W = wait for end of movement 

N = no wait for end of movement 

Stack: 

I_2 : (joint if pose_type= * J* | robtarget if 
pose_type= ' T * ) 

1_1: (joint if pose_type= * J' | robtarget if 
pose_type= ' T * ) 
=> (no result) 

Semantical explanation: 

I_2 : value of the intermediate pose 
I_l ; value of the destination pose 

Error code: 

-1 = time-out before the end of the movement execution 
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7.6.4 Polynomial interpolated movement (PMOVE) 

Control of a given movement of the robot to the next pose inside a defined curve in the geometrical 
referential (polynomial interpolation). The form of the curve until the next pose depends on the degree of 
the polynome. 

Group of compliance: group B, extensions 

Syntax: 

pmove : : = 

cd_pmove ' , ' abs_rel ' , ' pose_type ' , ' deg ' , ' wait . 
cd_j3move : : = ' PMOVE ' | pmove_code . 

pmove„code = 5 7 ( integer ) 

abs_rel = type of displacement (integer) 

1 = absolute 

2 = relative 

pose_type = pose type code (character) 

J = joint actuator values 

T = TCP pose in robot geometrical 
referential 
deg = degree of the interpolation polynome 

(integer) 
wait = specification that the application 

programme continues or not after PMOVE 

instruction without waiting for the end of 

the movement: 

W = wait for end of movement 

N = no wait for end of movement 

Stack: 

I_l: (joint if pose_type= ' J' | robtarget if 
pose_type=*T' ) 
=> (no result) 

Semantical explanation: 

I_l: value of the destination pose 

En^or code: 

-1 = time-out before the end of th^ movement execution 



7.6.5 Taught tr^ectory execution (MOVTRJ) 

Execution of a given robot trajectory given by using teach progranmiing. 

Group of compliance: group B, extensions 
Syntax: 



movtrj : := cd_movtrj ' , ' wait . 
cd_movtr j : : = ' MOVTRJ ' | movtrj _code 
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movtrj„code = 5100 (integer) 

wait = specification that the application 

programme continues or not after MOVTRJ 
instruction without waiting for the end of 
the movement: 

W = wait for end of trajectory execution 
N = no wait for end of trajectory execution 

Stack: 

I_l: integer 
=> (no result) 

Semantical explanation: 

I„l: number of the taught trajectory 

En'or code: 

-1 = time-out before the end of the trajectory 

execution 
-2 = unknown number of trajectory 



7.6.6 Robot calibration (CALIB) 

Control of a given robot movement to the specific calibration configuration of the axes. 

Group of compliance: group B, kernel 

Syntax: 

calib : := cd_calib ' , * axes_indic ' , ' wait . 
cd_calib : := 'CALIB' | calib„code . 

calib_code = 5200 (integer) 

axes_indic = integer value for identification of the 

axes to calibrate: 

each binary digit ordered i specifies if 
equal to 1 that the i axe must be 
calibrated. 

For instance, if axes 1, 3, 5 and 6 should 
be calibrated, the binary configuration of 
axes„indic will be '110101', that is '53' 

wait = specification that the application 

prograirane continues or not after CALIB 
instruction without waiting for the end of 
the movement : 

W = wait for end of trajectory execution 
N = no wait for end of trajectory execution 



Error code: 



-1 = unknown axe number 
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7.6.7 Movement to home pose (GOHOME) 

Control of the robot movement in joint coordinate system to the Home pose outside the working space. 

Group of compliance: group B, kernel 

Syntax: 

gohome : := cd_gohome ' , ' wait . 
cd_gohome : : = ' GOHOME ' | gohome_code . 

gohoine„code = 53 00 (integer) 

wait = Specification that the application 

programme continues or not after GOHOME 

instruction without waiting for the end of 

the movement : 

W = wait for end of movement 

N = no wait for end of movement 

Stack: 

I_l: joint 
=> (no result) 

Semantical explanation: 

I_l: value of Home configuration 

Error code: 

-1 = time-out before the end of the movement execution 



7.6.8 Beginning of path structure block (MOVBEG) 

Beginning of block structure for path execution by using xMOVE statements. The initial pose of the first 
xMOVE statement is the first pose of the path. 

Group of compliance: group B, extensions 

Syntax: 

movbeg : := cd_movbeg ' , ' wait . 
cd__movbeg : : = ' MOVBEG ' \ movbeg^code . 

movbeg_code = 5400 (integer) 

wait = Specification that the application 

programme continues or not after the next 
corresponding MOVEND instruction without 
waiting for the end of the path execution: 
W. = wait for end of path execution 
N = no wait for end of path execution 
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In the block structure, the path is defined by a set of xMOVE statements. The initial pose of the robot is 
the initial pose of the first xMOVE statement, the destination pose of the robot along the path is the 
destination pose of the last xMOVE statement and the other poses of the set of xMOVE statements are 
intermediate poses with velocity not equal to zero. 

It is possible to insert other statements like gripper control or sensor data acquisition into the block. These 
statements are executed at the end of the previous movement statement execution. 

If the wait' parameter is set to *N', all statements following the MOVEND statement out of the block 
structure are taken into account without waiting for the end of the path execution. 

7.6.9 End of the path structure block (MOVEND) 

End of the block structure of path execution. The destination pose of the last xMOVE statement is the last 
pose of the path. 

Group of compliance: group B, extensions 

Syntax: 

mo vend : : = cd_movend . 

cd_movend ::= 'MOVEND* | movend„code . 

movend_code = 5450 (integer) 

Error code: 

-1 = no corresponding MOVBEG statement 

This instruction closes a MOVBEG structure. The interpreter or the compiler will translate the set of 
xMOVE statements into a global path. 

7.6.10 Movement stop (MOVSTP) 

Stopping the robot movement. The robot stops a given movement. 

Group of compliance: group B, kernel 

Syntax: 

movstp : := cd_movstp ' , ' stop_type . 
cd_movstp : := 'MOVSTP' | movstp_code . 
cd_movstp = 5500 (integer) 
stop_type = type of stop movement 

1 = the robot stops using negative value of 

ACCEL system variable value 

2 = quick stop (using the max. deceleration 

value) 



Error code: 
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7.6.11 Movement continuation (MOVCONT) 

Movement continuation after Stop. This statement appears after MOVSTP statement occurence and the 
robot continues automatically to the initially programmed destination pose. This statement can appear 
into a path block structure. 

Group of compliance: group B, kernel 

Syntax: 

movcont : : = cd_inovcont . 

cd_movcont ::= 'MOVCONT' | movcont„code . 

movcont__code = 5 6 ( integer ) 

Error code: 

-1 = no movement is interrupted 



7.6.12 Movement cancellation (MOVCANCEL) 

Stopping the movement of the robot and cancellation of the destination pose. If the MOVECANCEL 
statement takes place in a block structure and is executed before a MOVEND statement, the robot stops, 
the path is cancelled and the {wrogranmie continues after the next corresponding MOVEND statement. 

Group of compliance: group B, kernel 

Syntax: 

movcancel ::= cd_movcancel . 

cd_movcancel ::= 'MOVCANCEL' | movcancel_code . 

movcancel_code = 5700 (integer) 

Error code: 

-1 = no movement is interrupted 



7.7 Exchange of data 

These statements manage to exchange character data and digital/analog data between the robot controller 
and external devices. Since inputs and outputs are hardware dependent, it is very difficult to make the 
standard of them. In the following subclause, the descriptions are made based on I/O mapped I/O. But this 
does not mean that ICR eliminates the use of memory mapped I/O. The mapping between I/O ports and 
the I/O addresses shall be done in the compiler/interpreter of ICR. 
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Syntax: 



dataexchange : : = 

cnfgchan | openchan | closechan | resetchan | statchan 



getch I putch 



getblk | putblk 



din I dout am aout 



7.7.1 Control of the communication channel 



The purpose of these statements is to establish and relinquish the communication linkage, or to monitor 
the status of the communication channels. 



7.7.1.1 Configuration of the communication channel (CNFGCHAN) 

This function is used to configure the communication channel in the robot controller. 

Group of compliance: group A, level 

Syntax: 

cnfgchan : : = cd_cnf gchan . 

cd_cnf gchan : : = ' CNFGCHAN » | cnf gchan_code . 

cnfgchan„code = 23100 (integer) 

Stack: 

l_5, I„4, I_3, I_2: integer, I_l:unsigned_integer 

=> (no result) 

Semantical explanation: 

I_l : port number of the communication channel 



I_2: If > 
If = 
If < 



future extension 

standard configuration (8-bit) 

controller dependend 

I_3 : actual baude rate 

1-4: parity: = no parity 

1 = even parity 

2 = odd parity 

I„5: stop bits: 0=1 stop bit 

1 = 11/2 stop bits 

Note If I_2 is less than zero, the specifications on these data (I_2 to L5) are 

dependent on the robot controller. 

Error code: 

= no error 

-1 = the configuration is not supported by the robot 
controller 
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7.7.1.2 Open communication channel (OPENCHAN) 

This function is used for request to open the conununication channel. 

Group of compliance: group A, level 

Syntax: 

openchan : : = cd_openchan . 

cd_openchan : : = ' OPENCHAN ' | openchan_code . 

openchan_code = 23200 ( integer ) 

Stack; 

I_l :unsigned_integer 
=> (no result) 

Semantical explanation: 

I_l: port number of the communication channel 



7.7.1.3 Close communication channel (CLOSECHAN) 

This function is used for request to close the communication channel. 

Group of compliance: group A, level 
Syntax: 

closechan ::= cd__closechan . 

cd_closechan ::= * CLOSECHAN* | closechan_code . 

closechan^code = 23250 (integer) 

Stack: 

I_l : unsigned_integer 
=> (no result) 

Semantical explanation: 

I_l: port number for the communication channel 
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7.7.1.4 Reset channel (RESETCHAN) 

This function is used for request to reset the communication error and initiate the settings. 

Group of compliance: group A, level 

Syntax: 

resetchan ::= cd__resetchan . 

cd_resetchan : : = ' RESETCHAN ' j resetchan_code . 

resetchan„code = 23300 (integer) 

Stack: 

I__l : uns igned_integer 
=> (no result) 

Semantical explanation: 

I__l: port number for the communication channel 

7.7.1.5 Get status of the channel (STATCHAN) 

This function is used for inquiry of the status of the conununication channel. 

Group of compliance: group A, level 

Syntax: 

statchan ::= cd_statchan . 

cd_statchan : : = ' STATCHAN ' | statchan_code . 

statchan_code = 23400 (integer) 

Stack: 

I_l :unsigned_integer 
=> 0_1 :unsigned_integer 

Semantical explanation: 

I_l: port number of the communication channel 
0_1: port number for the status buffer 

7.7.2 To exchange character data 

These statements are for reading/writing character data. 
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7.7.2.1 Get character (GETCH) 

This function is used for request to get one character from the communication channel. 

Group of compliance: group A, level 2 
Syntax: 

getch ::= cd_getch . 

cd_getch : :- ' GETCH ' | getch_code . 

getch__code = 23500 (integer) 

Stack: 

I_l : unsigned_integer 
=> 0„1 : character 

Semantical explanation: 

I_l : port number of the communication channel 
1: character 



7.7.2.2 Put character (PUTCH) 

This function is used for request to put one character to the communication channel. 

Group of compliance: group A, level 2 

Syntax: 

putch : : = cd_putch . 

cd_putch : : = ' PUTCH ' | putch_code . 

putch^code = 23510 (integer) 

Stack: 

I_2 : character , I„l : unsigned__integer 
=> (no result) 

Semantical explanation: 

I_2 : character 

I_l: port number of the communication channel 

7.7.2.3 Get communication block (GETBLK) 

This function is used for request to get some characters from the communication channel. 

Group of compliance: group A, level 2 



77 



IS 15035 : 2001 
ISO/TR 10562 : 1995 



Syntax: 

getblk ::= cd_getblk . 

cd_getblk : : = ' GETBLK * | getblk_code • 

getbl„code = 23550 (integer) 

Stack: 

I_2 : uns igned_integer , I_l : unsigned_integer 
=> 0_1 : string 

Semantical explanation: 

I_2: size of the data to be read in block_buf 
I_l: port number of the communication channel 
0„1: character string of the acquired data 



7.7.2.4 Put communication block (PUTBLK) 

This function is used for request to put some characters to the conununication channel. 

Group of compliance: group A, level 2 

Syntax: 

putblk ::= cd_putblk . 

cd_putblk ::= 'PUTBLK' ] putblk_code . 

putblk_code = 23560 (integer) 

Stack: 

I__3 : string, I_2 :unsigned_integer, 

I_l : unsigned_integer 
-> (no result) 

Semantical explanation: 

I_3 : character string to be sent 

I_2: size of the data to be put from block_buf 

1__1 : port number of the communication channel 

7.7.3 Digital and analog input/output 

These statements are used for exchanging the digital and analog data. 
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7.73.1 Digital data input (DIN) 

This function is used for request to input one digital data from the conununication channel. 

Groujf) of compliance: group A, level 

Syntax: 

din : : = cd_din . 

cd_din : : = ' DIN ' | din_code . 

din_code - 23 600 (integer) 

Stack: 

I_l :unsigned_integer 
=> 0_1 : unsigned_integer 

Semantical explanation: 

I_l: port number of the communication channel 
0_1: value of the acquired digital data 

7.7.3.2 Digital data output (DOUT) 

This function is used for request to output one digital data to the conmiunication channel. 

Group of compliance: group A, level 
Syntax: 

dout : : = cd_dout . 

cd_dout : : = ' DOUT ' \ dout_code . 

dout_code = 23650 (integer) 

Stack: 

I_2 :unsigned_integer, I_l :unsigned„integer 
=> (no result) 

Semantical explanation: 

I_2 : value of the data to be sent; 

1 for TRUE and for FALSE 
I_l: port number of the communication channel 

7.7.3.3 Analog data input (AIN) 

This function is used for request to input one analog data from the communication channel. 
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Group of compliance: group A, level 2 
Syntax: 

ain : : = cd_ain . 

cd_ain ::= 'AIN' | ain_code . 

ain_code = 23700 (integer) 

Stack: 

I_l : unsigned_integer 
=> 0_l:real 

Semantical explanation: 

I_l : port number of the communication channel 
0_1; value of the acquired analog data 



7.7.3.4 Analog data output (AOUT) 

This function is used for request to output one analog data to the communication channel. 

Group of compliance: group A, level 2 
Syntax: 

aout : : = cd_aout , 

cd__aout : : = ' AOUT ' | aout_code . 

aout_code = 23750 (integer) 

Stack: 

I„2 : real , I_l : unsigned_integer 
=> (no result) 

Semantical explanation: 

I„2 : value of the analog data to be sent out 
I_l : port number of the communication channel 

7.8 Data list management 

These statements are used for the manipulation of data lists. Data lists are used to separate intensively 
modifiable data or data that is likely to be modified from the program. Thus they can be handled by CAD- 
systems, teach-programming-procedures or text-editors. 
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The statements are used to create, define and operate on datalists, while file transfer is not a part of the 
language. 

Syntax: 

datalistop : := 

dlopen I dlgen | dlcls | dldel ] dlein | dleout . 



7.SA Open data list (DLOPEN) 

Opening of an existing data list. 

Group of compliance: group A, level 3 

Syntax: 

dlopen : : = cd_dlopen . 

cd_dlopen : : = * DLOPEN • | dlppen_code 

dlopen_code = 14100 (integer) 

Stack: 

I_l: string 
=> 0_1 : integer 

Semantical explanation: 

I_l: dl_name (data list name stored in the 

header of the datalist) 
0_1: dl_number (number of data list elements 

stored in the header of the data list) 

Error handling: 

If an error occurs when executing the operation, for instance if the data list does not exist, an 
errorcode is generated in the system variable ERRSPE. 

Errorcode: 

= no error 
-1 = data list does not exist 



7.8.2 New data list (DLGEN) 

A new data list is generated and opened. 

Group of compliance: group A, level 3 
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Syntax: 



dlgen : : = cd_dlgen , 

cd_dlgen : := 'DLGEN* | dlgen_code . 

dlgen_code = 14200 (integer) 

Stack: 

I_l : string 
=> (no result) 

Semantical description: 

l__l: dl_name (data list name stored in the 
header of the datalist) 

Enrorcode; 

= new data list created. 

-1 = data list already exist 

-2 = storage is not sufficient) 



7.8.3 Close data list (DLCLS) 

Closing a data list. 

Group of compliance: group A, level 3 

Syntax: 

dlcls ::= cd_dlcls . 

cd_dlcls ::= 'DLCLS' | dlcls_code . 

dlcls_code = 14300 (integer) 

Stack: 

I_l : string 
=> (no result) 

Semantical description: 

I_l : dl_name (data list name stored in the 
header of the datalist) 

En-orcode: 

= data list closed 
-1 = data list does not exist) 
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7.8.4 Delete data list (DLDEL) 

Delete a data list. 

Group of compliance: group A, level 3 

Syntax: 

dldel : := cd_dldel . 

cd„dldel ::= 'DLDEL' | dldel_code . 

dldel_code = 14500 (integer) 

Stack: 

I_l : string 
=> (no result) 

Semantical description: 

I__l : dl_name (data list name stored in the 
header of the datalist) 

Errorcode: 

= data list deleted 
-1 = data list does not exist) 



7.8.5 Reading data list element (DLEIN) 

Reading a data list element. The data of the data list element is given on top of stack. 

Group of compliance: group A, level 3 

Syntax: 

dlein : := cd_dlein ' , ' data_type . 
cd_dlein :;= 'DLEIN' | dlein_code . 

dlein_code = 14700 (integer) 

data_type = data type according to dldat_type 

(integer, see subclauses 6 . 1 .3 and 8,3) 

Stack: 

I_2 : string, I_l : string. 
=> 0_l:data type according to dldat_type (see above). 

Semantical description: 

I_l : dl_name (data list name stored in the header 

of the datalist) 
I_2 : dl_element (data element name stored in the 

element of the datalist) 

0_1: data (the value of the dldat_data of the data 
list element) 
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Errorcode: 

= successful operation 
<0 - operation stopped 
-3 = data list not opened 
-4 = data list element does not exist 
-5 = incompatible types) 



7.8.6 Writing data list element (DLEOUT) 

Writing of a list element. The element is given the data from value on stack. 

Group of compliance: group A, level 3 

Syntax: 

dleout : := cd_dleout ' , ' data_type . 
cd_dleout ::= 'DLEOUT' | dleout_code . 

dleout_„code = 14750 (integer) 

data_type = data type according to dldat_type 

(integer, see subclauses 6.1.3 and 8.3). 

Stack: 

I__3:data type according to data_type (see above), 

I__2 : string, I_l : string 
-> (no result) 

Semantical description: 

I_l: dl„name (data list ncime stored in the header 

of the datalist) 
I_2 : dl_element (data element name stored in the 

element of the datalist) 
I_3 : data (the value to be stored in the data 

list element) 

Errorcode: 

>0 = operation effectually executed 

1 = New element added 

2 = Modify existing element 
<0 = operation stopped 

-2 = storage not sufficient 

-3 = list not opened 

-5 = incompatibility of data. The already existing entry 
was not overwritten because its data type is not 
compatible with the one indicated in type. 
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7.9 Description of robot facilities 

Instructions for limitation of working space, robot kinematics, end effector description and others. 

Syntax: 

description : : - 

limit I worksp | prosp | efna | tcp_def 

7.9.1 Limitation of axis range (LIMIT) 



Limitation of the range of axis operation. 

Group of compliance: group B, extensions 
Syntax: 



limit 



;= cd limit 



ax no 



min max 



cd_limit ::= 'LIMIT' | limit_code . 



limit_code 
ax_no 

min„max 

axis_limit 



axis limit 



3100 (integer) 

axes number, Integer 

Min or max limit definition. Integer 

= min limit 

1 = max limit 

address or constant of the limit value. 
Real. The limit value is defined in 
percent of the operation range for each 
axis. Valid values - 100 % 



7.9.2 Working space definition (WORKSP) 



Working space definition in cartesian coordinates of an ashlar. 

Group of compliance: group B, extensions 
Syntax: 

worksp : := cd_worksp ' , ' min_max • , * wsp_limit 
cd__worksp : :- 'WORKSP' | worksp_code . 



worksp_code 
min max 



wsp_limit 



3200 (integer) 

Min or max limit definition, Integer 

= min limit 

1 = max limit 

(Input parameter adr. ) Position 
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This instruction defines a workspace for the valid TCP. In a cartesian coordinate system minimum or 
maximum coordinate values are indicated in mm. 



7.9.3 Prohibited area (PROSP) 

Definition of a prohibited area. 

Group of compliance: group B, extensions 

Syntax: 

props : := cd_jprosp ' , ' min_max * , ' psp_limit . 
cd_prosp : = ' PROSP ' | prosp_code . 

prosp_code = 3300 (integer) 

min„max = Min or max limit definition. Integer 

~ min limit 

1 = max limit 

psp_limit = {Input parameter adr. ) Position 

This instruction defines a prohibited area for the valid TCP inside a working space defined by the 
WORKSP instruction. 



7.9.4 Selection of an end effector (EFNA) 

General call of an end effector. 

Group of compliance: group B, extensions 
Syntax: 

efna : := cd_efna * , ' data_type * , ' eef_label . 
cd_ef na ; : = ' EFNA ' | ef na„code . 

efna_code = 17100 (integer) 

data_type = data type of the end effector label. Integer 

eef_label = (Input parameter adr.) String/Integer 

This instruction enables the selection of a certain end effector that is known to the robot controller. The 
end effector data is used in all following movement instructions. 
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7.9.5 Definition of the TCP (TCP_DEF) 

Define the coordinates of the end effector center point. 

Group of compliance: group B, extensions 
Syntax: 

tcp_def : := cd„tcp__def ' , * data_type ' , * ef fector_label * , ' 

data__type2 ' , * ef fector_data . 
cd_tcp_def : : - ' TCP_DEF ' \ tcp_def _code . 

tcp_def_code = 17200 (integer) 

data_type = data type of the effector number (Integer) 
ef fector_label = ( input parameter address ) (Integer) 
data_type2 = data type of the effector data 
ef fector_data = ( input parameter address ) (Integer) 

Position, Orientation, Pose 



7*10 End effector control 

Functions for the end effector control will be defined in an upcoming edition. 

7.11 Sensor functions 

The sensor functions will be defined in an upcoming edition. 

7.12 Concurrent programming functions 

The functions for concurrent programming will be defined in aii upcoming edition. 

7.13 Debugging functions 

Syntax: 

debugf unction : := 

checkon I checkoff . 



87 



IS 15035 : 2001 
ISO/TR 10562 : 1995 



7.13.1 CHECKON 

This function can be used for switching on the range checking of arithmetic operations. 

Group of compliance: group A, level 5 
Syntax: 

checkon : : = cd_checkon . 

cd_checkon : : = ' CHECKON ' | checkon_code . 

checkon_code = 18100 ( integer) 



7.13.2 CHECKOFF 

This function can be used for switching off the range checking of arithmetic operations. 

Group of compliance: group A, level 5 
Syntax: 

checkoff ::= cd_checkoff . 

cd„checkoff ::= 'CHECKOFF' | checkof f.code . 

checkoff _code = 18150 (integer) 

7.14 User specific extensions 

The code numbers from 28000 to 31999 are reserved for user specific extensions. These extensions 
should follow the syntax structure of ICR, but can contain any functions and data. 

Note The use of user-specific extensions should be restricted to the absolute 

minimum, because the portability of programs and data will be reduced. 



7.15 Future extensions 

The code numbers from 25000 to 27999 are reserved for future extensions of ICR. 
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8 Data list definition 



These statements are used for the definition of data lists. Data lists are used to separate intensively 
modifiable data or data that is likely to be modified from the program. Thus they can be handled by CAD- 
sy stems, teach-progranuning-procedures or text-editors and quite separate from the program handling. 

This chapter only describes the structure of the stored data list with its header, data list elements and end 
elements. The operations on such datalists and data elements from an ICR program are described in 7.8. 



8.1 Header of data list (DLHEAD) 

The first element (header) of a data list is always DLHEAD. 
Syntax: 

dlhead : : = cd__dlhead * , ' dl_naine ' , ' dl^number . 
cd_dlhead : : = ' DLHEAD ' | dlhead_code . 

dlhead_code ^ 24000 (integer) 

dl_name = Data list name (ASCII string) 

dl_niiinber = Number of data list elements (integer) 



8.2 End of data list (DLEND) 

The last element of a data list is always DLEND. 
Syntax: 

dlend : := cd„dlend ' , ' dl„name . 

cd_dlend ::= 'DLEND' | dlend_code . 

dlend_code = 24999 (integer) 

dl_name = Data list name (ASCII string) 



8.3 Element of data list (DLDAT) 

An element of a data list is described as follows: 
Syntax: 

dldat : : = cd__dldat * , ' dldat_name ' , * dldat_type 

' , ' dldat_data . 
cd_dldat : : = ' DLDAT ' | dldat_code 



89 



IS 15035 : 2001 
ISO/TR 10562 : 1995 



dldat_code = 24500 ( integer ) 

dldat_name = Data element name (ASCII string) 

dldat_type = Data type description (integer) 

(see data types) 
dldat_data = Constant corresponding to the data type 

(constant) 
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Annex A 

(informative) 

Robot system state variables 



The robot system state variables are described with respect to ISO/IEC 9506-3, which is referred to as the 
MMS/RCS (Robot Companion Standard) in this Technical Report. When they are used or referred to in 
the intermediate code, make reference to ISO/IEC 9506-3. 
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Annex B 

(informative) 

Implementation guide 



B.l Introduction 



This implementation guide is provided to facilitate the implementation of ICR; it should not, however, be 

regarded as an implementation specification. 

ICR is a pseudo-machine level programming code. The pseudo-machine used for ICR interpretation is 
defined by the instruction descriptions in this Technical Report. It is a stack based machine with explicit 
input/output statements. The data stack is explicit, whereas the program return stack is implicit. This has 
as a consequence the protection of subroutine and exception return addresses. The variables may be either 
local or global. To allow the recursion local variables should be on the stack, the global variables may be 
on the stack, or in a separate variable pool, depending on the implementation. 

ICR has a similarity to the P-code used to implement several Pascal compilers/interpreters *\ 

The design of an ICR implementation can generally be divided into two main areas: the implementation 
of an interpreter/executor and the implementation of specific high-level or intermediate-level 
programming language compilers which generate ICR. Generally the interpreter design should be much 
more straightforward, because it can be directly based on the description and specification of ICR 
instructions, provided that the proper pseudo-machine design is done and all appropriate internal code 
related decisions are properly taken. 



B.2 Interpreting ICR 

ICR is a code, existing in two conformancy classes, two flavours: numeric code (where all the code 
elements are specified as strings of ISO 8859-1 numerals, and human-readable symbolic code (where all 
the code elements are specified as mnemonics, i.e. using the whole ISO 8859-1 character set). In both 
situations the ICR should be converted to the intemal form used by the controller. This conversion will 
usually be done by a so-called "loader", a preprocessor programme. 

In the case of the lower conformance class, which requires numerical representation of codes, the 
conversion, "loading" will involve converting the ISO 8859-1 numerical strings into intemal binary, BCD 
(or whatever other) representation. This can be either a straightforward conversion, or a remapping. The 
straightforward conversion will primarily be used in an ICR interpreter optimized for speed of 
conversion, as for example in a controller which is directly fed with the ICR strings, so that the 
conversion is done line by line and consequently its speed directly influences the execution time of the 
ICR instructions. A more common approach will be to convert the external numerical ICR representation 
into the internal form by remapping all of the code elements. This will require a slightly longer 



1) For a thorough description of a Pascal compiler generating the P-code» as well as the description of the P-code interpreter, 
the book 5. Pamberton, M. C. Daniels: PASCAL Implementation, Ellis Harwood, Chichester 1983, ISBN 0-85312-482-5 could 
be consulted. This book will give a lot of relevant information concerning pseudo-machine programming code 
implementation. 
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conversion time. It will, however, enable different types of optimization. In this way one can optimize, for 
example, the execution speed or the memory sp)|ce requirement of the resulting internal code. The 
execution speed could be optimized by usilJg a tight mapping which will enable the interpreter's selection 
statemfent (e.g. the 'CASE statenoeiit in t^i$c^, 'switch' statement in C etc.) to be efficiently programmed. 
The nijcmory space requirement t6iM b^ optimized by a specific selection of very short, short, long and 
very lc|ng (in number of bits) internal words, varying depending on the typical usage frequency of specific 
ICR ijlistructions. Commonly a selection of optimization criteria will be used. One example of the 
necessity for that kind of optimizations is a production of a non-pseudo, real hardware (micro- )processor 
which l^ill directly execute the ICR code (in an internal form). 



B.2J Pseudo-machine organization 

This Technical Report does neither specify nor require any number of internal interpreter (executor) 
machine registers. However, it is obvious that a LIFO stack pointer for data processing, possibly another 
LIFO subroutine return stack pointer (if the data stack is not used for both purposes), a linear program 
counter with a possibility of random loading and changing (for program and subroutine jumps) and a 
data-list read/write (or separate read and write) pointer will be necessary. Furthermore to optimize 
recursion and static/dynamic block inclusion execution, static and dynamic mark pointer(s) may be 
included as well. 

As for the robot control itself, several state variables, probably as internal registers or fixed memory 
mapped locations, are necessary to be included. This will generally involve the kinds of "Acceleration" 
register. "Deceleration" register, "Velocity" register, "Move^time" register, current position register, 
destination position register and many others. Those will mainly reflect the ICR instructions for technical 
specifications of this Technical Report. 

Further data/status registers will be required for the specifications for the movement control and probably 
others, as well as the status/data registers associated with the end effector/effectors. 

Input/output channels will have to have tables which will contain their status information (i.e. 'InputOnly', 
'OutputOnly', 'InputOutput', 'TransferSpeed', 'ProtocolType' and/or others). Those tables will generally be 
dependent on the concrete equipment used. 

To facilitate the MMS communications (see Informative Annex A) a separate part of the interpreter will 
be involved. 

The ERROR codes will require a separate global register, as it is explained in this Technical Report. 



B.2.2 Strings 



The string data type in ICR is a pseudo-dynamic data type. It is fully dynamic on the stack. The strings 
are static (fixed physical length) variables if declared with DECLVAR, with a fixed length whose 
minimum is defined. This fixing is necessary due to the limitations a stack frame based machine imposes. 

As ICR specification tries to enforce only explicit data type-casting, the implementation of dynamic top- 
of-stack strings could involve dynamic scratch memory and pointers from top of stack to that area, where 
all changes to the string would be executed. This kind of implementation will prove to be much faster if 
long strings are often pushed onto and popped from the stack. However, as such implementation is not 
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strictly conformant to this Technical Report, it is strongly discouraged. If it is absolutely necessary to do 
such a trick (in highly execution-time optimized interpreters) it should be employed with great caution. 
The main problem can be caused by compilers and human writers of ICR making implicit data type 
casting by using the knowledge of top of stack organization in a particular moment. 



B.2.3 Dynamic memory allocation 

ICR specification does not impose any particular method of memory management and possible dynamic 
memory garbage collection. Furthermore, this Technical Report does not include memory allocation and 
deallocation functions, which will be defined in an upcoming edition. However, the implementor should 
have in mind that a lot of programming languages use true dynamic memory allocation and therefore also 
many compilers will use allocation and deallocation in the same spirit. There are several ways to 
implement the dynamic memory allocation, but it would go out of the scope of this document to describe 
those. 



B.2.4 Conversion and casting of data types 

Although ICR specification does prefer explicit data type casting and conversion it is arguable if the 
implementation should strictly enforce this condition. It is possible to attain that reasonably easy by 
adding type specifying information (typically several bits, or one byte) with each value on stack. This 
certainly would boost the security of ICR interpretation, but would disable existence of compilers for 
certain languages which prefer implicit casting by leaving a value (e.g. at the exit of a function) on top of 
the stack and using it later as another type (the most common usage of such type intermixing is with 
integers and booleans). Another possible solution is to have a tag array for each stack entry. This would 
leave the stack properly organized for implicit casting and enable the interpreter to have an explicit 
checking and an implicit non-checking mode. Both of those solutions are execution-time consuming. 



B.2.5 Data accessing 

As ICR is a stack based machine, most of the variables will be contained in different stack frames. It is a 
prerequisite for the interpreter to enable proper access of stack frames from the top level local scope 
downwards to the global level. This means that a variable access would first search for it in the most 
recent local DECLVAR stack pool (in the current frame), then on the next deeper level of stack (the next 
deeper stack frame) and so on, until it is found declared in a DECLVAR statement, worst case as a global 
variable. It is possible to introduce common variables known to the controller itself in an interpreter 
provided they are the last ones checked. This enables local variables to take precedence to those on higher 
syntactical levels, precedence of local variables to global ones, and precedence of global variables to 
controller defined commons. 

This method of accessing data is easiest to implement by dynamic and static mark pointers. It should be 
noted that the data from the most recently active block from each static syntactical level (text block 
nesting level) should always be accessed. This means that there should be made a strict distinction 
between the textual structure of the ICR programme and the executed structure of the ICR progranmie. 
Proper handling of this is an absolute must, as many languages and their compilers will use recursion! 
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The necessary mark pointers can be put on the data stack, or kept separately on a stack marking stack. 
They will be handled by the SUBPBEG, SUBPEND and BLKBEG, BLKEND instructions. 

B.2.6 Procedure calling conventions 

It is specified that the procedure parameters are passed over the stack. To enable this the interpreter has to 
obey a few rules. Normally the parameters would be pushed on the stack before CALL is executed. The 
CALL instruction should not alter the state of the data stack. As now normally a new block and stack 
frame would be started it is important to enable the procedure statements access to the parameters. To 
allow this the DECLVAR should be the first instruction (if the procedure has parameters). 



B.2.7 Function calling conventions 



The function calling sequence is the same as for procedures. However, the return value should be left on 
the top of the stack at the end of the function procedure. The SUBPEND statement should not change the 
data stack. Subsequent instructions in the main program stream would find the function return value on 
top-of-stack for further processing, as if a normal ICR instruction would have been executed instead of 
the function call. 



B.2.8 Jump instructions 



It is necessary to design interpretation of jump instructions properly, as they may jump out of the scope of 
blocks. This is particulary important (and hard to implement) in the case of jumps out of a stack framed 
block structure. It is important to note that jumps always follow the textual structure of the programme. 
That is to say that a jump out of a block should follow the static mark links, not the dynamic marks. The 
implementation of jumps will be closely related to the mark pointers associated with stack frames. A 
jump out of a (series of) block(s) will behave as if it has effectively executed all the associated BLKEND 
instructions. Consult also subclause B.2.5. 



B,2,9 Hints for usage of ICR 



The usage of an ICR interpreter does not make special demands on the concept or implementation of the 
robot movement specific part of a robot controller. An ICR interpreter can be implemented as a sq)arate 
module that can be plugged onto an existing robot controller. The more complex functions that are not 
robot movement specific shall be implemented as a part of the ICR interpreter itself, as for example the 
arithmetic or the stack handling mechanism. 
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Figure B.l - Connection of ICR-Interpreter and robot controller 

The connection to the robot movement nintime system and the process or user input/output modules can 
be established by an internal manufacturer specific interface. This interface can be partly procedural. The 
interface to the movement runtime system is recommended to be implemented by a buffering memory 
structure, e.g. a FIFO (first-in-first-out) to avoid strong time dependencies between the ICR interpreter 
and the movement runtime system (i^). 

Only if the movement runtime system is to be influenced by fast sensor information evaluated by the ICR 
interpreter, more effort has to be put on this problem in order to get a closer time coupling between ICR 
interpreter and movement runtime system (ixx)- 

ICR can be thought of as a low-level code interface between a programming system and a robot 
controller. The programming system can either be situated online on the robot controller or offline on an 
external programming device or even both. The programming methods of the programming system can 
range from simple non-structured instruction languages to high-level structured languages or CAD 
systems. Especially for the implementation of low cost robot controllers ICR can be a good choice as a 
producer independant standardized low-level programming interface. 

According to the progranmiing system, a program debugging system can be implemented online and/or 
offline, too. The debugging tools should support manufacturer specified interfaces to the high-level 
programming systems (ii) in order to enable high-level debugging and to the ICR interpreter (i2) in order 
to control the program flow and to examine or change data values. 
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Figure B.2 - Interfaces between a high-level programming and debugging system and an ICR 

interpreter 



B.3 Compiling into ICR 



ICR is a general pseudo-low-level programming code enabling translation from any high-level language. 
To enable this, appropriate compilers will have to be written. Different high-level or intermediate-level 
programming languages (or even progranmiing codes) will be translated into ICR. Consequently each of 
the tr^slations will employ different, for the translated language appropriate, usage of ICR facilities. The 
ICR interpreter/executor will not be aware of those differences. That is to say that very different ways of 
using the data and variable declarations and block structures can be used by the compiler, as long as they 
conform to the statement descriptions in this Technical Report. Reasonable care has to be involved in 
doing this, as in this process the machine can get into severe stack based problems. 

Here, a few examples of possible implementation details for major language types are given. Those are 
examples only, and should not be used as specifications for a compiler design. 



B.3.1 General 



All self-contained ICR programs will start with PBEG and end with PEND. However, those two 
statements do not start up the basic stack frame. Consequently only programs which have no declared 
variables (i.e. do not need variable space on the stack) could be written without the BLKBEG / BLKEND 
instruction pair. For all other programs the BLKBEG instruction would be followed by DECLVAR. 



B,3.2 BASIC type robot languages 



This is a type of programming languages which is characterized by simple linear algorithmization, no 
separate compilation modules, no data and algorithm abstraction, few strictly predefined data types and 
simple non-parameterized subroutine calling sequences. Programming languages of this type can, 
naturally, be expanded with simple or more complex structured syntactical organizations, but then they 
start falling into some of the later described language types. Generally BASIC type languages can be 
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either compiled, or more often interpreted on a line-by-line basis. In both cases the lines of the original 
language would be translated directly into ICR, and then executed. This is preferable to the interpretation 
of the high-level language by an interpreter written in ICR. It is possible to do the line-by-line 
incremental compilation of this type of languages, as their structure does not necessitate complex parsing 
algorithms, because each statement (a line or, rarely, a collection of lines) is syntactically independent. 

Into this type would also fall the older FORTRAN (and similar) languages, with the exception of the 
subroutine/function calling sequences, which are parameterized. For this reason (and furthermore as 
modern FORTRAN, or e.g. RATFOR are fully structured languages) the actual compilation and 
implementation of those would be very similar to the implementation of PASCAL type. Though in certain 
cases it would still be possible to do incremental compilation, but rarely line-by-line interpretation. 
Furthermore, FORTRAN allows separate compilation, so a linker should be provided. 



B.3.3 Pascal type robot languages 

This type of languages is characterized by strict syntactical structure enforcing, and enforcing of so-called 
structured programs. All procedures and functions are (or at least can be) parameterized and the languages 
are hierarchically block structured. Variables may be global or local to a procedure/function. Usually 
recursion is allowed and fairly simple to obtain. Certain languages from this type (like MODULA 2 or 
ADA) allow modular programming. 

The implementation of modular programmes should not be a problem as the compiler/linker would 
resolve all external declarations and combine all involved modules into one executable ICR programme, 
which would then be downloaded into the controller. However, in certain cases it is preferable to have the 
possibility of dynamic linking. This would involve the existence of a special dynamic linker in the 
controller and the possibility of high speed access to long-term programme storage. The standard version 
of ICR does not directly support dynamic modules, so a special progranmiing effort in the native 
controller programming code should be made to allow that. 

Although the order of parameters on the stack is not relevant for interpretation, to enable parameter 
passing between different compilers and languages, it is strongly suggested that the parameters are pushed 
on the stack in the same sequence they are encountered in the original language, from left to right. That is 
to say that the leftmost high-level language parameter would be pushed on the stack first, the rightmost 
parameter would be on top of the stack. 

It is important that strict blocking is done for each procedure/function/module, as the reserving of stack 
space for variables is depending on that. 

As the ICR does not distinguish procedures from functions, it is necessary explicitly to clean the stack of 
all the procedure parameters at the end of the procedure, after the last BLKEND statement, but before the 
SUBPEND instruction. For functions the return result should be left on top-of-stack just before 
SUSPEND. One way to do this would be to first pop it from the stack into a temporary variable (from any 
of previous stack frames or globals) before the BLKEND is executed, then explicitly dispose of all the 
parameters, and finally, just before SUBPEND, push it back on the stack. 
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B.3.3.1 C subtype robot languages 



The C subtype is primarily characterized by the inclusion of the possibility to declare local variables in 
any block (in C delimited by the symbols '{' and '}') and by the indistinguishability of subscripted arrays 
and pointers. The implementation of block-local variables is directly supported by ICR instructions 
BLKBEG and DECLVAR. The second characteristic of C subtype languages does pose a slight problem. 
ICR specification prefers explicit data type casting, whereas some languages very often use implicit 
casting (the interchangeability of arrays and pointers is only one of more such implicit castings in e.g. C). 
For the specific problem of arrays vs. pointers cautious use of ELAADR should be implicitly mixed with 
proper (dynamic) variable addresses. The problem of other implicit castings (not data-conversions!) is a 
conceptual one. If the implementation of ICR interpreter does not enforce explicit top-of-stack type 
checking there should be no problem. However, it is suggested that the compiler produces, as often as it is 
not absolutely impossible, proper explicit ICR casting/conversion instructions. Special care should be 
taken in the common implicit casting of integers and booleans, specifically because byte sex can differ 
from one ICR implementation to another. 



B.3.4 LISP type robot languages 

This type of high-level languages is primarily characterized by single or multiple linked lists processing 
and general interchangeability of data and program. However, even for that type of languages a compiler 
could be written. These languages require proper memory management and garbage collection utilities. 
As these languages require quite specific implementation techniques it is suggested to consult appropriate 
literature (e.g. W.M. Waite: Implementing Software for Non-Numeric Applications, Prentice-Hall, 
Englewood Cliffs 1973, ISBN 0-13-451898-5). 



B.3.5 APL and the likes 



This is a language type with very weak variable typing, which means that all the conversions (e.g. real 
scalar to integer matrix or character vector to boolean array) are done implicitly, depending on the 
operators. This can be achieved either by using dynamic variables or by a combination of available ICR 
types and dynamic variables. Programs of this language type would probably be developed off-line and 
then compiled into ICR, except when a on-line CAP system is to be designed. In that case an efficient 
language interpreter should be designed, where all the language elements would be executed by fixed ICR 
routines and the whole system would be driven by a simple parser. The execution of this type of 
languages by ICR is facilitated by their general data-related strict leveling structure, which will easily be 
transferred into a strictly stack-based structure. (For further details involved in APL-like language 
parser/interpreter construction R. Zacks: An APL Implementation For Microcomputers, Sybex 1978 could 
be consulted.) 



B.3.6 FORTH type robot languages 



This type of languages (into which, except FORTH proper, mostly stack-based pseudo-machine 
programming codes with macro extensions could be counted) is characterized by stack-based operations 
and unlimited expansion possibilities, which virtually enable them to emulate any other kind of 
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programming language. Those languages are quite closely related in their execution principles to ICR. A 
major problem in implementing FORTH itself in ICR is the inclusion of multiple stacks, which should be 
simulated. Further problems can be expected in the decision of using compilation techniques or ICR 
programmed interpreter. 



B.3.7 Object-oriented and other languages 

It would be outside of the scope of this annex to describe possible implementations of other languages. It 
has to be noted, however, that most of commonly used object-oriented languages (e.g. C++) could easily 
fall into one of the above mentioned categories. Those have then be expanded for the inclusion of object 
descriptions. Partly ICR directly supports complex objects and with them associated operations in the 
field of robotics. Though those would not fall directly into the scope of what is called "object-oriented", 
they still can provide a simple insight into what could be simulated by the use of other ICR instructions. 
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Annex C 

(informative) 

National comments 



There are some points of the ICR definition, which have to be discussed in the future. Some of the 
national member bodies want to document their comments and to express their wish for changes or 
corrections. In the following the original contribution from the countries is given with minor editorial 
changes. 



C.l Comments from Italy 



We disagree with a standard for the intermediate code for robot (ICR) for either philosophical reasons or 
technical reasons. 

We think that the final users would have no benefit from ICR standardization, because they will mainly 
use high level languages or user-friendly graphical interfaces for robot programming. This fact will 
become even more evident in the future, with the new generation of robot controllers. 

It is worthwhile to remember that the standardization efforts in the information technology has been 
developed for high level languages, leaving to the computer manufacturers the burden of developing the 
low level interfaces with their hardware. For robotics application, PLR has the same role as C languages, 
whereas the ICR has the role of Assembly level languages. 

ICR standardization would have the same effect of having a standard assembler language for different 
computers, but still using different high level languages. Thus ICR standardization would pose 
unnecessary restrictions to the development of robot controllers without any practical benefit for anyone. 

From a more technical point of view, the actual committee draft of ICR does not support many 
functionalities that are required today in the industrial robot market. The capability of handling multi- 
robot coordination or developing user interfaces is not supported, for example. (In the "Comments of CD 
10562.2" from GMFanuc Robotics corporation, many other limitations are clearly pointed out). 

Thus even if a sense could be given to the standardization of a low level language as ICR, the actual 
status of ICR is not satisfactory for the needs of modem robot controllers. 



C.2 Comments from Japan 



C.2.1 Entire document 

There are many important issues that are not discussed enough in the meetings. They are addressing 
modes (especially absolute address), code numbering, description of constants, assumed controller 
architecture, implementation guide in annex A2, and so on. 
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C,2.2 Entire document 



Mixture of postfix notation and prefix notation (stack operation) causes inconsistencies in design 

philosophy and in the description of instructions. 



C.2.3 Clause 2 



Because of the hmitation of 7-bit coded character set, some countries which employ 8-bit coded character 
set cannot use 8-bit coded characters especially in character strings. 

C.2.4 Subclause 5.5 

Line numbers with every statement cause redundancy in code length. Too much redundancy is placed in 
ICR. ICR will not be executable even in future. 

C.2.5 Subclause 6,1.3 

There are not enough numeric data types; it only provides 4-byte integer and 4-byte real. 
G,2.6 Subclause 6.2 

Comment 1: 

The range of 4-byte integer is from -214748364S, not -2147483642 in case of personal computers and 

workstations. 

Comment 2: 

The range of 4-byte real assumes floating point expression standard IEEE-754. 

C.2.7 Subclause 6.5 

There is no reason why matrix representation of orientation is excluded, since several representations are 
allowed. 

C.2.8 Subclause 7.6.5 

(MT) The data representation of taught trajectory must be specified. How does ICR deal with the spray 
gun ON/OFF while moving in teach programming, for example? 



C.3 Comments from Poland 



C.3.1 General comments 

1.1 It is a very good document; it has collected and systematised many concepts which were, hitherto, left 
to the realizators of software for industrial robots and were not standardized in any way. It is, therefore, a 
very extensive material with regard to both the physical volume and the technical content. 

1.2 The draft presented constitutes only the first part of the standard. This should be clearly said in the 
introduction together with a mention of the second part and its scope. Although this information may be 
found in the draft but scattered little by little in many places. 
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C«3.2 Basic technical comments 

C.3.2.1 ad. figure 2 

A programming unit should be added. It may be an operator console, monitor etc.; it means any 
communication device between operator and robot control system. 

This addition is rational i.a. because references to such device are made in further text e.g. 6.1.3 - "The 
data type STRING allow to handle text information, e.g. to react on user terminal input ...". 

2.2 For functions, instructions intended for the development in the second part or for user's specific 
extensions appropriate code areas should be assigned now (cL 7.10; 7.11; 7.12; 7.14; 7.15). This will 
enable to avoid excessive freedom of ICR implementation which could lead to development of varied 
versions, whose codes would not be interchangeable. 

2.3 Subclause 6.3 is generally not very clear. In our opinion it is advisable to separate descriptions of 
constants and variables. 



C.33 Detailed technical comments 

(all accepted, corresponding changes made in present version of ICR document) 

C.3.4 Editorial comments 

4il In the list of content not only subclause number but also number of page should be specified. 

4.2 At the end of such extensive document an index is necessary. 

4.3 Addenda should be complemented by the summary of instruction nmemonics and their codes. 

4.4 There is a number of minor mistakes in this draft, removal of which requires a lot of time. For 
example: subclause 7.3.13 in the instruction definition areas "instruction number" have been specified 
twice (line 9 and 14) while it is evident that the second time area "symbol" is meant. 

C.4 Comments from Sweden 

C.4.1 General comment 

We do not agree to the circulation of the draft as a DIS for the following reasons: 

Due to the limitations in the use of ICR, which is a consequence of the unidirectional communication 
between a progranmiing system and the robot system, the ICR is not very well suited to industrial 
requirements. ICR does not fit in a structure diagram where a programming system and the robot control 
use the same language, or where the program language used in the robot control can be translated back to 
the high level language used in a programming system. 

An intermediate code must be related to the high level language in such a way that there is a one-to-one 
correspondence between the high level instruction and the instruction codes in the intermediate code. 
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Consequently the work on ICR should be postponed until a high level language has been defined, and 
then, if required, continue with the high level language as a basis. 

If ICR will be published ahead of PLR we fear that the development of PLR will be influenced in a not 

favourable way. 

As a possible alternative we recommend that ICR should be published as an ISO/TR which would allow 
that the ICR could be used in its present form, if someone so wishes. 

The transformation of ICR from TR into IS should be decided at a later stage when PLR is published. 



C.5 Comments from USA 

C.5.1 Part 1 

C.5.1.1 Entire Document 

There is a significant variance between the content of the Scope clause (clause 1) and the scope implied 
later in the document. Clause 1 implies that the scope of the standard is solely the specification of the 
information which moves from a robot programming system to the robot control unit (figure 5.1). Later 
on, the document seems to sp)ecify the implementation of an interpreter for this language. This leads to the 
question: which system will be evaluated for conformance to the standard, the system which generates the 
ICR (the robot programming system) or the system which interprets it (the robot)? This is very important 
when we start specifying conformance. 

C.5.1.2 Clause 4 

Comment 1: 

The position of this clause is very strange. Most standards include their compliance clause after the body 

of the standard, typically as the last clause before the annexes. I don't understand why this clause is here 

and recommend that it be moved to a later position in the text. Even stranger is the fact that only the first 

paragraph talks about compliance; the remainder of the clause seems to be high level organizational 

material. 

Comment 2: 

Fourth paragraph - The use of the term 'level' implies a progressive adoption, i.e. level 3 implies level 2, 
etc. However, the sentence says that something is 'independent' from each other. Is level the right term to 
use here? 

C.5.1.3 Subclause 5.3.3 

Description of the stack operation - What is the purpose of this clause? This would appear to place some 
requirements on the robot control system. However, the Scope clause says only that the standard covers 
the form of transmission of the ICR. If this is needed to establish the semantics of the ICR, that fact needs 
to be stated before the stack is described. Otherwise, the meaning of this stack is unclear. 

The notation is very confusing. I have seen push down stacks described in simpler terms than this. Also, 
is there an implication that the stack has a fixed width, say 32 bits? This also needs to l)e described. 
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C.5.2 Part 2 

Common shared intermediate code does not allow for a robust execution architecture without heavy 
penalties in both program execution speed, and program execution system implementation complexity. 

Because any source can be used for generation of complex intermediate code sequences that can have 
direct control over the movement and operation of the robot controller, extensive error checking and 
consistency checking is required by the program interpreter at run-time. 

This run-time checking will produce: 

- slow execution of ICR coded programs since it CAN NOT be assumed that these programs are 

correct in either format or content. To do so would sacrifice safety and proper operation of the robot 
controlled system. 

(Alternatively the requirement for larger more expensive computers to run even simple robotic 
applications with a level of performance available today with robotic controllers using relatively 
inexpensive computer technology. This will increase the cost of even the simplest robotic system.) 

- No opportunities for local optimization between the program translator and the program interpreter to 

take advantage of architectural features unique to the robot control system. 

Proposal of Change: 

Focusing on high level robot progranuning language definition that does not require the use of a 
common intermediate representation. 

Level of specification for draft standard proposal supports functionality used only in the most 
basic/simple robotic applications. Typical robotic applications which require sophisticated motion, data 
handling, process, and user interface support are not covered by the proposal. 

Extensions made outside of the proposed specification which are required to provide functionality 
common to applications done today will make these programs non-portable, eliminating the advantages of 
a standard intermediate code representation. 

Proposal of Change: 

Extensive extension of the proposed ICR definition to include functionality used today in industrial 
robotics applications. This should include consideration of: 

- Multi-motion device and auxiliary motion control devices. 

- Process integration support with robotic motion. 

- User interface and sophisticated file device support. 

- Process and controller operation error handling. 

C,5.2.1 Subclause 7.7.1.2 Comment For Reason For Change: 

Programs need the ability to direct input/output operations to devices other than a generic "port." In some 
robot languages, read and write statements are separate from open statements that identify the physical 
device to which the operations are directed. 

Proposal of Change: 

- The OPEN command needs to be able to specify a file in a storage device, either built-in to or 

attached to the controller. Typically, this requires specificafion of a storage device, file name, and 
file type specifier. Whether the file is to be read, updated, or re-written needs to be specified. 
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Input/output operations also need to be directed to display devices (teach pendant and CRT) and/or 
keyboards. 

In general, a program interacts with multiple channels. Typically, these are all opened during 
initialization. Thus, OPENCHAN needs to associate a channel number with the physical entity 
(port, file, display device and/or keyboard) accessed through the channel. 



C.5.2.2 Subclause 7.7.2.1.3 Comment For Reason For Change: 

Programs require ability to read entity values, not just character information. Although it may be possible 
to accomplish such a read with a series of single character reads and many other operations, the resulting 
code would be very large and slow to execute. 

Proposal of Change: 

' A GET command should specify the data type and address of the operand. (Alternatively, the operand 
may be left on the stack, but for some cases, e.g. large structures or arrays, this may not be 

practical.) 

- A GET command should provide for transmission of raw (unformatted, binary) data or data 

consisting of character representation of data, with the GET command supplying format 
information (such as number base and whether to skip over sonie characters). 

- There needs to be provision for time-out of GET operations. 

- There needs to be provision for handling of errors (end of file, format errors). 

C.5.2.3 Subclause 7.7.2.2.4 Comment For Reason For Change: 

Proposal of Change: 

- Programs require the ability to transmit data either in raw (binary) form or formatted into readable 

character strings, 

- The PUT commands should include information on the data type and formatting instructions. This 

can be fairly extensive. Some examples are display of reals, with and without exponents, integers in 
various bases, and left- or right-justified strings. 

- Mechanisms for setting cursor position (or, for files, file position) and display modes (e.g., blinking. 

large character size) are required. 

C.5.2.4 Subclause 7.3 Comment For Reason Change: 

Programs require the ability to specify asynchronous processing. 

Proposal of Change: 

- The ability to specify a condition, or combination of conditions, in which some action(s) are required 

and the actions to be taken. 

- The ability to enable and disable such a specification. 

- The conditions available should include occurrence of specified errors, digital and analog port input 

values, semaphores, program pause, resume or termination, variable values, and progress through a 
move or sequence of moves (for example, some specified period of time before a specific position is 

reached). 
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Comment For Reason For Change: 

There are many uses in robot programs for measuring the passage of time, or triggering some action at 
some time in the future. One approach to this is to in effect make a clock, or timer, out of a variable. 
Once this is done, the variable is automatically updated at fixed intervals by the number milliseconds 
since the last update. The ability to stop this updating process is also required. 

Proposal of Change: 

' Provide an instruction to start updating the value of an integer variable at regular intervals by the 
number of milliseconds since the last update. 

- Provide an instruction to terminate this updating process. 

- Actions available should include routines to call, but may include a sequence of statements. 

- Some provision for specifying the relative priority of asynchronous interrupt handlers is required. 

C.5.2.5 Subclause 5.3.3 Comment For Reason For Change: 

It is often useful for a program to access a variable whose name is not known at compile time. For 
example, a program could obtain a list of names of variables, display this list, permit the operator to select 
a name, and then operate on the selected variable. This requires accessing variables at run-time by name. 

Proposal of Change: 

- An instruction is required which loads an array with a list of names of variables of a specified type 

and associated with a specified program name. 

- An instruction which would use as input the name of a variable (including program name and field 

names, if any), and generate the address of the variable. 

C.5.2.6 Subclause 7.3.6 Comment For Reason For Change: 

It is frequently required for a "shell" program to obtain and display a list of "part" programs, permit the 
operator to select one, and call this program, even though when the shell program was written, the names, 
or even the number, of part programs were not known. 

Proposal of Change: 

- A facility is needed to obtain, in an array of strings, a list of programs loaded on the controller. 

- A form of the CALL command is required in which the name of the routine to be called is in a string 

at run-time, not in the intermediate code. 

Comment For Reason For Change: 

There is no specification for built-in routines. 

Proposal of Change: 

A standard library of built-in routines should be defined for ICR. A built-in would be called similar 
to a procedure, but with a pre-defined name and pre-defined parameters. Listed below are some 
proposed categories of built-ins: array handling, access data and programs by name, communication 
operations, error code handling, file and device operations, serial I/O and file usage, memory 
operations, position mirroring, program and motion control, multi-progranuning, path operations, 
string conversions, time-of-day operations, user interface menus, process I/O setup, and line- 
tracking operations. 
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C.5.2.7 Subclause 6.5 Comment For Reason For Change: 

There is no specification for dynamic paths. 

Proposal of Change: 

A new data type called path should be added which is made up of an optional path header, defined 
by a record, and one or more path nodes, defined by another record. Paths must be static variables 
and the path nodes can be dynamically created during program execution or during teach mode. The 
move instruction would specify a path to move along and the start and end nodes. Other information 
for concurrent motion needs to be specified, as discussed in the concurrent motion proposal. 

Related instruction or built-ins to append a node, delete a node, insert a node, return the node size, 
and return the number of nodes are required. 
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D.l Data types and others: 



BRADR 


blockrelative_address 


INT 


INTEGER 


REAL 




BOOL 


BOOLEAN 


CHAR 


CHARACTER 


STR 


STRING 


reserved 




reserved 




POS 


Position 


ORI 


Orientation 


POSE 


Position and orientation 


JOINT 


Robot joints 


M JOINT 


Main joint 


A JOINT 


Additional joint 


ROBTRT 


Robot target 


REMARK 


Comment record 


DECLVAR 


Global variable declaration 


TYPEDEF 


Type definition 


D.2 Program flow control (22000) 


PBEG 


beginning of program 


PEND 


end of program 


PSTOP 


program execution stop 


CALL 


wocedure call 


BLKBEG 


seginuing of a block 


BLKEND 


block end 


SUSPEND 


end of subroutine and return 


LABEL 


Subroutine begin or target for a jump 


GOTONR 


go to instruction number 


GOTOSYM 


go to symbol 


IFNR 


logically conditional go to an instruction number 


IFSYM 


logically conditional go to a symbolic label 


JMP DEC NR 


Jump or decrement 


JMP DEC SYM 


Jump or decrement 


NOOP 


no operation 


DELAY 


delay of program execution 


WAIT BNR 


Wait for binary input 


WAIT BSYM 


Wait for binary input 


WAIT LENR 


Wait for analog input (less or equal) 


WAIT LESYM 


Wait for analog input (less or equal) 


WAIT GENR 


Wait for analog input (greater or equal) 


WAIT GESYM 


Wait for analog input (greater or equal) 


PAUSE 




TEACHON 


start teach-in mode 


CHECK AXES 


Check number of axes 


CHECK ORI 


Check orientation description type 





1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

1000 

500 

700 



22100 
22150 
22190 
22200 
22300 
22310 
22220 
22400 
22420 
22430 
22450 
22460 
22470 
22480 
22999 
22600 
22620 
22630 
22640 
22650 
22660 
22670 
22700 
22800 
22850 
22860 
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CHECK_BR Compare stack values and branch 

CHECK_BR_SYM Compare stack values and branch 

D.3 Boolean and arithmetic operations (21000) 



22870 
22880 



ari_ 
opl_ 
code 


opl_ 
sym- 
bol 


type 

of 

result 


type 

of 

oper. 


explanation 


21005 


ABSI 


INT 


INT 


absolute value 


21010 


ABSR 


REAL 


REAL 


absolute value 


21015 


NORM 


REAL 


POS 


norm of a vector 


21020 


NEGI 


INT 


INT 


negation of integer 


21025 


NEGR 


REAL 


REAL 


negation of real 


21030 


NEGP 


POS 


POS 


negation of posit. 


21035 


ROUND 


INT 


REAL 


rounding a real 


21040 


TRUNC 


INT 


REAL 


truncation of real 


21045 


FLOAT 


REAL 


INT 


convert integer 


21050 


FLTMl 


REAL 


INT 


convert integer 


21055 


ORD 


INT 


CHAR 


convert a character 


21060 


CHR 


1 CHAR 


! INT 


convert a ntunber 


21065 


1 BOOL I 


1 INT 


1 BOOL 


convert boolean 


21070 


1 CTTJ 


1 JOINT 


1 ROBTRT 


convert robtarget 


21075 


1 CTJT 


1 ROBTRT 


1 JOINT 


convert joint 


21080 


1 SQRT 


1 REAL 


1 REAL 


square root 


21085 


1 SIN 


REAL 


1 REAL 


sine -function 


21090 


COS 


1 REAL 


1 REAL 


cosine-function 


21095 


TAN 


1 REAL 


1 REAL 


t angens - f unc t i on 


21100 


AS IN 


1 REAL 


1 REAL 


inverse sine-funct. 


21105 


1 ACOS 


1 REAL 


1 REAL 


1 inverse cosine- fun. 


21110 


1 LN 


1 REAL 


1 REAL 


natural logarithm 


21111 


1 EXPN 


1 REAL 


1 REAL 


1 natural exponentat. 
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ari_ 
op2_ 
code 


op2„ 
sym- 
bol 


type 
of 
result 


types 

of 

operands 


explanation 


21X15 


1 ADDER 


BRADR 


BRADR BRADR 


address addition 


21120 


; MULBR 


BRADR 


BRADR INT 


addr . multiplicat . 


21125 


ADDI 


INT 


INT INT 


addition of int. 


21130 


ADDR 


REAL 


REAL REAL 


addition of reals 


21135 


ADDP i 


POS 


POS POS 


addition of pos. 


21140 1 


ADDJ 


JOINT 


JOINT JOINT 


addition of joints 


21145 1 


ADDEP 1 


POSE 


POSE POS 


pose translation 


21150 1 


SUBI i 


INT 


INT INT 


subtraction of int 


21155 1 


SUBR 1 


REAL 


REAL REAL 


subtraction ( real ) 


21160 1 


SUBP 1 


POS 


POS POS 


subtraction of pos 


21165 


SUBJ 


JOINT 


JOINT JOINT 


subtract . ( j oints ) 


21170 


SUBEP 


POSE 


POSE POS 


pose translation 


21175 


MULI 


INT 


j INT INT 


i multiplicat. (int) 


21180 


MULR 


REAL 


1 REAL REAL 


; multiplicat. real 


21185 


MULPI 


POS 


1 POS INT 


multiplic. by int. 


21190 


MULPR 


1 POS 


1 POS REAL 


1 multipl. by real 


21195 


ROTP 


POS 


! POS ORI 


position-rotation 


21200 


ROTO 


ORI 


1 ORI ORI 


orientation-rotat . 


21205 


TRANS P 


POS 


1 POSE POS 


posit ion- transfer. 


21210 


ROTE 


1 POSE 


1 POSE ORI 


pose-rotation 


21215 


jTRANSE 


1 POSE 


1 POSE POSE 


1 pose-trarisf ormat . 


21220 


1 DIVI 


! INT 


1 INT INT 


division of int. 


21225 


1 DIVR 


1 REAL 


1 REAL REAL 


division of reals 


21230 


1 DIVPI 


1 POS 


1 POS INT 


division by int. 


21235 


1 DIVPR 


1 POS 


1 POS REAL 


1 division by real 


21240 


; MOD 


1 INT 


1 INT INT 


1 modulof unction 
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ari_ 
op2_ 
code 


op2_ 
sym- 
bol 


type 
of 
result 


types 

of 

operands 


explematlon 


21245 


RELE 


POSE 


POSE POSE 


pose-relation 


21250 


ATAN2 


REAL 


REAL REAL 


inverse temgens 


21255 


EQB 


BOOL 


BOOL BOOL 


equality of bool. 


21260 


EQC 


BOOL 


CHAR CHAR 


equality of char. 


21265 


EQI 


BOOL 


INT INT 


equality of int. 


21270 


EQR 


BOOL 


REAL REAL 


equality of reals 


21275 


EQP 


BOOL 


POS POS 


equality of posit. 


21280 


EQO 


BOOL 


ORI ORI 


equality of orien. 


21285 


EQE 


BOOL 


POSE POSE 


equality of poses 


21290 


EQS 


BOOL 


STR STR 


equality of string 


21295 


1 NEB 


BOOL 


1 BOOL BOOL 


inequality of bool 


21300 


1 NEC 


j BOOL 


1 CHAR CHAR 


inequality of char 


21305 


1 NEI 


1 BOOL 


1 INT INT 


inequality of int 


21310 


1 NER 


1 BOOL 


1 REAL REAL 


1 inequality of reals 


21315 


1 NEP 


1 BOOL 


1 POS POS 


1 inequality of pos. 


21320 


1 NEO 


1 BOOL 


1 ORI ORI 


1 inequality of ori 


21325 


NEE 


1 BOOL 


1 POSE POSE 


1 inequality of poses 


21330 


NES 


1 BOOL 


1 STR STR 


1 inequality of str 


21335 


1 GTI 


1 BOOL 


INT INT 


1 comparison > int 


21340 


GTR 


1 BOOL 


REAL REAL 


1 comparison > real 


21345 


LTI 


1 BOOL 


1 INT INT 


comparison < int 


21350 


1 LTR 


1 BOOL 


1 REAL REAL 


1 comparison < real 


21355 


1 GEI 


BOOL 


1 INT INT 


1 comparison >= int 


21360 


1 GER 


1 BOOL 


1 REAL REAL 


comparison >= real 


21365 


LEI 


BOOL 


1 INT INT 


1 comparison <= int 


21370 


1 LER 


1 BOOL 


1 REAL REAL 


comparison <= real 
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D.3.1 Boolean and bitwise operations witli one operand 



b_ 

opl_ 

code 


b_ 
opl_ 
symbol 


type 
of 
result 


type 

of 

operand 


explanation 


21375 NOTE | BOOL | BOOL | negation of boolean] 


21380 1 NOTI 1 INT INT [negation of integer] 



D.3.2 Boolean and bitwise operations with two operands 



b_ 

op2„ 

code 



b_ 


type 


op2_ 


of 


symbol 


result 



types 

of 

operands 



explanation 



21385 


ANDB 


BOOL 


BOOL 


BOOL 


log. 


conjunct.bool 


21390 


ANDI 


INT 


INT 


INT 


log. 


conj . bit/bit 


21395 


ORB 


BOOL 


BOOL 


BOOL 


log. 


disjunct. bool 


21400 


ORINT 


INT 


INT 


INT 


log. 


disj. bit/bit 


21405 


XORB 


BOOL 


BOOL 


BOOL 


log. 


exclusive or 


21410 


XORI 


INT 


INT 


INT 


log. 


excl. or bitw 
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D.3.3 Generation operations 



gen_ 

op_ 

code 


gen_ 
symbol 


type 
of 
result 


types 
of 
components 


explanation 


21415 


GENP 


POS 


REAL, REAL, 
REAL 


generation of a POS 
from three reals 


21420 


GENO 


ORI 


INT, REAL, 
REAL, REAL, 
REAL 


generation of an ORI 
from one integer and 
four reals 


21425 1 GENE | POSE |POS, ORI [generation of a pose 


21430 


GENERO 


POSE 


REAL, REAL, 
REAL, ORI 


generation of a pose 
from 3 reals and ori 


21435 


GENEPR 


POSE 


POS, INT, 
REAL, REAL, 
REAL, REAL 


generation of a pose 
from a position, one 
integer and 4 reals 



21440 



GENERR 



POSE 



REAL, REAL, 
REAL, INT, 
REAL, REAL, 
REAL, REAL 



generation of a pose 
from three reals, one 
integer and four 
reals 



21441 


GENT 


ROBTRT 


POSE, INT, 

INT 

A_JOINT 


generation of a rob- 
target 


21442 


GENM 


JOINT 


REAL, . . . 


generation of a 
M_JOINT from reals 


21443 


GEND 


A_ 
JOINT 


REAL, . , . 


generation of a 
A_JOINT from reals 


21444 


GENJ 


JOINT 


M_ JOINT, 
A_JOINT 


generation of JOINT 


21445 


GENJRD 


JOINT 


REAL, . , . , 
A_JOINT 


generation of a 
JOINT 


21446 


GENJMR 


JOINT 


M_ JOINT, 
REAL, . . . 


generation of a 
JOINT 


21447 


GENJRR 


JOINT 


REAL, . . . , 
REAL, . . . 


generation of a 
JOINT 
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str_ 

op_ 

code 


str_ 
op_ 
symbol 


type 

of 

result 


types 
of com- 
ponents 


explanation 


21450 


APPENDCl STR 


STR, CHAR 


char append to str 


21455 


CONCATS STR 


STR, STR 


string concatenat. 


21460 


EXTRCTS 


STR 


STR, INT, 
INT 


extract a part of a 
string 


21465 


GETCHR |CHAR 


STR, INT 


get one character 


21470 


SETCHR 


STR 


STR, CHAR, 
INT 


set one character 
into the string. 


21475 


LENGTHS 1 INT 


STR 


get the str length 



D.3,5 Stack operations 

D.3.5.1 Push and pop operations with consta'nt size 



pap_op_ 
code 


pap_op_ 
symbol 


type of 
operand 


explanation 


21480 


PUSHB 


BOOL 


push boolean value on TOS 


21485 


PUSHC 


CHAR 


push char value on TOS 


21490 


PUSHI 


INT 


push int value on TOS 


21495 


PUSHR 


REAL 


push real value on TOS 


21500 


PUSHP 


POS 


push posit. value on TOS 


21505 


PUSHO 


ORI 


push ori value on TOS 


21510 


PUSHE 


POSE 


push POSE value on TOS 


21515 


PUSHT 


ROBTRT 


push robot target on TOS 


21520 


PUSHJ 


JOINT 


push joint value on TOS 


21525 


PUSHS 


STR 


push string value on TOS 


21530 


PUSHA 


BRADR 


push operand value on TOS 


21531 


PUSHER 


BRADR 


push blockrelative address 


21532 


PUSHAA 


abs . addr 


push absolute address 


21535 


POPE 


BOOL 


pop bool to abs. addr. /symb 
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pap_op_ 
code 



pap_op_ 
symbol 



type of 
operand 



explanation 



1 21540 1 POPC 1 CHAR | pop character | 


1 21545 1 POPI 1 INT 1 an integer is popped | 


1 21550 1 POPR 1 REAL | a real is popped | 


1 21555 1 POPP 1 POS 1 a position is popped | 


1 21560 1 POPO 1 ORI |an orientation is popped | 


1 21565 1 POPE 1 POSE | a POSE is popped | 


1 21570 1 POPT 1 ROBTRT | a robtarget is popped | 


1 21575 1 POPJ 1 JOINT | a joint is popped | 


1 21580 1 POPS STR | a string is popped | 


1 21585 1 POPA 1 BRADR | an address is popped | 


1 21590 1 DUPB 1 BOOL | duplicate the boolean | 


1 21595 1 DUPC 1 CHAR | duplicate the character | 


1 21600 1 DUPI 1 INT 1 duplicate the integer | 


1 21605 1 DUPR 1 REAL | duplicate the real | 


1 21610 1 DUPP 1 POS 1 duplicate the position | 


1 21615 1 DUPO 1 ORI 1 duplicate the orientation | 


1 21620 1 DUPE 1 POSE | duplicate the pose | 


1 21625 1 DUPT 1 ROBTRT | duplicate the robtarget | 


1 21630 1 DUPJ 1 JOINT | duplicate the joint | 


1 21635 1 DUPS STR | duplicate the string | 


1 21640 1 DUPA 1 absolute! duplicate the absolut ad- | 


21645 1 SWAPB ] BOOL | swap boolean values | 


1 21650 1 SWAPC 1 CHAR | swap character values | 


1 21655 1 SWAPI 1 INT | swap integer values | 


1 21660 1 SWAPR t REAL | swap real values | 


1 21665 1 SWAPP 1 POS | swap position values | 


21670 1 SWAPO 1 ORI swap orientation values | 
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pap_op_ 
code 


pap_op_ 
symbol 


type 6f 
operand 


explanation 


216 


75 


SWAPE 


POSE 


swap POSE values 


216 


BO 


SWAPT 


ROBTRT 


swap robot target values 


216 


t— — 

85 


SWAPJ 


JOINT 


swap joint values 


21690 


SWAPS 


STR 


swap string values 


21695 


SWAPA 


absolute 


swap absolute addresses 



D.3.5.2 Push and pop operations with variable size 



pap_ 
opv„ 
code 


pap_ 

opv_ 

symbol 


size 


type of 
operand 


explanation 


21700 


PUSHV 


actual 
size 


const/abs. 
addr/symb. 


push value with the 
given size 


21705 


PUSH 


actual 
size 


- 


•size' bytes on the 
stack are allocated 


21710 


POPV 


actual 
size 


absolut 
address 
or symbol 


a value with the 
given size is popped 
to the abs. addr/sym 


21715 


POP 


actual 
size 


- 


•size' bytes on the 
stack are released 


21720 


LOAD 


actual 
size 


- 


the abs. address or 
symbol repl . by val. 


21725 


STORE 


actual 
size 


- 


store value on TOS 


21726 


PUSHVD 


type 


blockrel . 
address 
or symbol 


push value of size 
according to the 
specified type 


21727 


POPVD 


type 


blockrel . 
address 
or symbol 


pop value of size 
according to the 
specified type 


21728 JLOADVD | type | - | load value on TOS 


21729 


STOREVD 


type 
size 


- 


store value of TOS 
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D.3.5.3 Push and pop operations with variable number of elements of fixed data type 



pap__ 

opvft__ 

code 


pap„ 
opvft_ 
symbol 


explanation 


21730 


PUSHFD 


a field is pushed on TOS 


21731 


POPFD 


j a field is popped of the TOS 



D.3.6 Operations for address calculation 



PUSHSZ 

addJdist 



Push the size of array element on TOS 
Add distance to address field 



21735 
21740 



D.4 Technical specifications (2000) 

R_ACCEL Reading the movement acceleration 2000 

W_ACCEL Writing the movement acceleration 2050 

R__VEL Reading the movement velocity 2100 

W_VEL Writing the movement velocity 2150 

R_MOVTIM Access to the duration of a movement 2200 

W„MOVTIM Setting up the duration of a movement 2250 

MVTMOUT Setting up a time-out of a movement 2300 

RD_ACCDP Reading the robot accuracy on destination 2400 

W__ACCDP Writing the robot accuracy on destination 2450 

RD„ACCIP Reading the robot accuracy on intermediate 2500 

W_ACCIP Writing the robot accuracy on intermediate 2550 

IDENTIR Identification of the current robot 2700 

SELECTIR Selection of the current robot 2800 

CURPOS Pose access 2900 



D.4.1 Movement control (5000) 



JMOVE 

LMOVE 

CMOVE 

PMOVE 

MOVTRJ 

CALIB 

GOHOME 

MOVBEG 

MOVEND 

MOVSTP 

MOVCONT 

MOVCANCEL 



Movement specified by joint interpolation 5010 

Linear interpolated movement 5030 

Circular interpolated movement 5050 

Polynomial interpolated movement 5070 

Taught trajectory execution 5 1 00 

Robot calibration 5200 

Movement to home pose 5300 

Beginning of path structure block 5400 

End of the path structure block 5450 

Movement stop 5500 

Movement continuation 56(X) 

Movement cancellation 5700 
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D.4.2 Exchange of data (23000) 



CNFGCHAN 

OPENCHAN 

CLOSECHAN 

RESETCHAN 

STATCHAN 



Configuration of the communication channel 23 100 

Open communication channel 23200 

Close communication channel 23250 

Reset of communication channel 23300 

Get status of the channel 23400 



D.4.3 To exchange character data 



GETCH 
PUTCH 
GETBLK 
PUTBLK 



Get character 

Put character 

Get communication block 

Put communication block 



23500 
23510 
23550 
23560 



D.4.4 Digital and analog input/output 



DIN 
DOUT 
AIN 
AOUT 



Digital data input 
Digital data output 
Analog data input 
Analog data output 



23600 
23650 
23700 
23750 



D.4.5 Data list management (14000) 



DLOPEN 


Open data list 


DLGEN 


New data list 


DLCLS 


Close data list 


DLDEL 


Delete data list 


DLEIN 


Reading data list element 


DLEOUT 


Writing data list element 



14100 
14200 
14300 
14500 
14700 
14750 



D.4.6 Description of robot facilities (3000 & 17000) 



LIMIT 
WORKSP 
PROSP 
EFNA 
TCP DEF 



Limitation of axis range 
Working space definition 
Prohibited area 
Selection of an end effector 
Definition of the TCP 



3100 

3200 

3300 

17100 

17200 



D.4.7 Debugging functions (18000) 

CHECKON 
CHECKOFF 



18100 
18150 



D.4.8 User specific extensions 

The code numbers from 28000 to 3 1999 are reserved for user specific extensions. 
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D.4.9 Future extensions 

The code numbers from 25000 to 27999 are reserved for future extensions of ICR. 



D.5 Data list derinition (24000) 

DLHEAD Header of data list 24000 

DLEND End of data list 24999 

DLDAT Element of data list 24500 
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